CVE-2026-57819: JAX-RS form parameter flood enables

CISO Take

Apache CXF's JAX-RS message handling ships without a default cap on the number of form parameters it will parse, so an unauthenticated attacker can send a single HTTP POST with tens of thousands of form fields and drive CPU/memory exhaustion on any exposed endpoint. This matters because CXF is a widely embedded Java web-services framework, and any internally built AI inference gateway, agent orchestration API, or model-serving REST layer written on top of it inherits the same unbounded-parsing behavior — with network access, no auth, and no user interaction required (CVSS 7.5, AV:N/AC:L/PR:N/UI:N). EPSS sits low (0.47%, ~61st percentile) and there's no public exploit, PoC, Nuclei template, or KEV listing, so this reads as opportunistic-DoS risk rather than an imminent campaign; CISA's own SSVC decision is TRACK, not act-now. The fix is trivial: upgrade to CXF 4.2.3, 4.1.8, or 3.6.12 (default limit of 500 params), or set `maxFormParameterCount` explicitly on any JAX-RS endpoint you can't patch immediately, and add request-size/param-count limits at the reverse proxy as defense in depth.

Sources: NVD EPSS CISA KEV ATLAS OWASP LLM Top 10 lists.apache.org

What is the risk?

High severity (CVSS 7.5) but low near-term exploitation likelihood: the flaw is trivially triggerable (no auth, no complex payload, low attack complexity) which keeps sophistication at 'trivial', but low EPSS, absence from CISA KEV, no public exploit code, and an SSVC 'TRACK' decision indicate it has not attracted active attacker interest. Impact is confidentiality/integrity-neutral and availability-only (C:N/I:N/A:H) — this is a pure resource-exhaustion bug, not a data-exposure or RCE path. Risk should be treated as moderate-and-patchable rather than urgent, but any internet-facing JAX-RS endpoint (including AI service APIs) is a valid target the moment it's discovered.

How does the attack unfold?

Entry point

Attacker locates an internet-facing JAX-RS endpoint on an AI-related service built on an unpatched Apache CXF version and sends an unauthenticated HTTP POST.

AML.T0049

Resource exhaustion

The POST body contains tens of thousands of form parameters; since no default maxFormParameterCount is enforced, CXF parses every field, consuming excessive CPU and memory.

AML.T0034.001

Service impact

The affected JAX-RS service (e.g., an AI inference API or agent orchestration endpoint) becomes unresponsive or crashes, denying service to legitimate users.

AML.T0029

Entry point

Attacker locates an internet-facing JAX-RS endpoint on an AI-related service built on an unpatched Apache CXF version and sends an unauthenticated HTTP POST.

AML.T0049

Resource exhaustion

The POST body contains tens of thousands of form parameters; since no default maxFormParameterCount is enforced, CXF parses every field, consuming excessive CPU and memory.

AML.T0034.001

Service impact

The affected JAX-RS service (e.g., an AI inference API or agent orchestration endpoint) becomes unresponsive or crashes, denying service to legitimate users.

AML.T0029

How severe is it?

CVSS 3.1

7.5 / 10

EPSS

0.5%

chance of exploitation in 30 days

Higher than 39% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AV Network

AC Low

PR None

UI None

S Unchanged

C None

I None

A High

What should I do?

1 step

1) Upgrade Apache CXF to 4.2.3, 4.1.8, or 3.6.12, which introduce a default maxFormParameterCount of 500. 2) If immediate upgrade isn't possible, explicitly set maxFormParameterCount (or equivalent JAX-RS provider configuration) to a conservative value on every exposed endpoint. 3) Enforce request body size and parameter-count limits at the reverse proxy/WAF layer (e.g., Caddy, nginx, CloudFront) in front of any Java-based AI API, independent of application-layer fixes. 4) Add monitoring/alerting for anomalous CPU/memory spikes correlated with large form-encoded POST bodies on JAX-RS endpoints. 5) Inventory internal services for Apache CXF usage (SBOM/dependency scan) since it's often an indirect dependency of Java-based API frameworks rather than a headline component.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable Yes

Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

DoS Framework API AML.T0029 - Denial of AI Service AML.T0034.001 - Resource-Intensive Queries AML.T0049 - Exploit Public-Facing Application

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

NIST AI RMF

MEASURE 2.7 - AI system resilience to attacks and disruption is evaluated

OWASP LLM Top 10

LLM10:2025 - Unbounded Consumption

Frequently Asked Questions

What is CVE-2026-57819?

Apache CXF's JAX-RS message handling ships without a default cap on the number of form parameters it will parse, so an unauthenticated attacker can send a single HTTP POST with tens of thousands of form fields and drive CPU/memory exhaustion on any exposed endpoint. This matters because CXF is a widely embedded Java web-services framework, and any internally built AI inference gateway, agent orchestration API, or model-serving REST layer written on top of it inherits the same unbounded-parsing behavior — with network access, no auth, and no user interaction required (CVSS 7.5, AV:N/AC:L/PR:N/UI:N). EPSS sits low (0.47%, ~61st percentile) and there's no public exploit, PoC, Nuclei template, or KEV listing, so this reads as opportunistic-DoS risk rather than an imminent campaign; CISA's own SSVC decision is TRACK, not act-now. The fix is trivial: upgrade to CXF 4.2.3, 4.1.8, or 3.6.12 (default limit of 500 params), or set `maxFormParameterCount` explicitly on any JAX-RS endpoint you can't patch immediately, and add request-size/param-count limits at the reverse proxy as defense in depth.

Is CVE-2026-57819 actively exploited?

No confirmed active exploitation of CVE-2026-57819 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-57819?

1) Upgrade Apache CXF to 4.2.3, 4.1.8, or 3.6.12, which introduce a default `maxFormParameterCount` of 500. 2) If immediate upgrade isn't possible, explicitly set `maxFormParameterCount` (or equivalent JAX-RS provider configuration) to a conservative value on every exposed endpoint. 3) Enforce request body size and parameter-count limits at the reverse proxy/WAF layer (e.g., Caddy, nginx, CloudFront) in front of any Java-based AI API, independent of application-layer fixes. 4) Add monitoring/alerting for anomalous CPU/memory spikes correlated with large form-encoded POST bodies on JAX-RS endpoints. 5) Inventory internal services for Apache CXF usage (SBOM/dependency scan) since it's often an indirect dependency of Java-based API frameworks rather than a headline component.

What systems are affected by CVE-2026-57819?

This vulnerability affects the following AI/ML architecture patterns: model serving, agent frameworks, inference APIs.

What is the CVSS score for CVE-2026-57819?

CVE-2026-57819 has a CVSS v3.1 base score of 7.5 (HIGH). The EPSS exploitation probability is 0.47%.

What is the AI security impact?

Affected AI Architectures

model servingagent frameworksinference APIs

MITRE ATLAS Techniques

AML.T0029 Denial of AI Service

AML.T0034.001 Resource-Intensive Queries

AML.T0049 Exploit Public-Facing Application

Compliance Controls Affected

EU AI Act: Article 15

NIST AI RMF: MEASURE 2.7

OWASP LLM Top 10: LLM10:2025

What are the technical details?

Original Advisory

Apache CXF allows to set a limit on the number of form parameters in a JAX-RS message via the "maxFormParameterCount" configuration option. However, no default limit is set which may lead to denial of service attacks when processing requests with very large numbers of form parameters. Users are recommended to upgrade to versions 4.2.3 or 4.1.8 or 3.6.12, which fix this issue by using a default limit of 500 parameters.

Exploitation Scenario

An attacker identifies a JAX-RS endpoint on an internet-facing service built on an unpatched Apache CXF version — for example, a Java-based AI agent orchestration API or model-management console that accepts form-encoded POST requests. Without needing credentials, the attacker sends a single HTTP POST containing tens of thousands of form parameters. Because no default limit exists, CXF attempts to parse every parameter, consuming disproportionate CPU and memory on the server thread handling the request. Repeated or concurrent requests of this kind exhaust available worker threads/resources, rendering the AI service unresponsive to legitimate users — a low-effort denial-of-service requiring no reconnaissance beyond finding a reachable JAX-RS endpoint.

Weaknesses (CWE)

CWE-400 Uncontrolled Resource Consumption Primary CWE-400 Uncontrolled Resource Consumption

CWE-400 — Uncontrolled Resource Consumption: The product does not properly control the allocation and maintenance of a limited resource.

[Architecture and Design] Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.
[Architecture and Design] Mitigation of resource exhaustion attacks requires that the target system either: The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question. The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker. recognizes the attack and denies that user further access for a given amount of time, or uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.

Source: MITRE CWE corpus.