Apache CXF EUVD-2026-53852

The target must be running an unpatched Apache CXF version (pre-3.6.12, pre-4.1.8, or pre-4.2.3) and must expose at least one JAX-RS endpoint that accepts form-encoded request bodies (Content-Type: application/x-www-form-urlencoded or multipart/form-data) without having explicitly configured 'maxFormParameterCount'. No special privileges or authentication are required by the vulnerability itself - any client able to reach the HTTP endpoint can trigger the condition. Exploitation is limited by any application-level authentication gate on the endpoint, network-layer controls (firewalls, rate limiting), or a pre-existing explicit 'maxFormParameterCount' setting in the CXF configuration.

No NVD CVSS score has been published at time of analysis, so severity must be inferred from the description and CWE. The attack vector is network (any JAX-RS endpoint reachable over HTTP/HTTPS), complexity is low (a crafted POST with a high parameter count suffices), and no authentication is inherently required by the vulnerability itself - though application-layer auth on the endpoint would limit exposure. EPSS data was not supplied. Neither a public proof-of-concept nor a CISA KEV listing exists, indicating exploitation is theoretical rather than observed. The practical risk depends heavily on whether JAX-RS form-accepting endpoints are internet-facing or internal-only: internet-facing deployments of unpatched CXF are genuinely at risk of targeted DoS, while internal-only deployments have a substantially reduced threat surface. The availability of clear vendor-confirmed fix versions and a straightforward upgrade path keeps remediation priority moderate-to-high for internet-exposed services.

An unauthenticated attacker sends a rapid series of HTTP POST requests to a publicly accessible Apache CXF JAX-RS endpoint, each carrying tens of thousands of form parameters in the request body. CXF parses every parameter without bound, progressively consuming heap memory and CPU on the application server until the JVM experiences out-of-memory errors or garbage collection thrashing, resulting in service unavailability for legitimate users.