Apache CXF EUVD-2026-53851

The vulnerability is exploitable against any Apache CXF endpoint that handles multipart message attachments (SOAP with attachments or multipart REST) AND where the operator has not explicitly configured the 'attachment-max-size' parameter. Services that do not process multipart/attachment payloads are not affected by this code path. Exploitation is limited by: (1) the presence of a multipart-capable CXF endpoint reachable by the attacker; (2) whether the endpoint requires authentication - if so, the attacker must possess valid credentials; (3) upstream infrastructure such as reverse proxies, load balancers, or API gateways that impose their own request-body size limits, which would block oversized payloads before they reach CXF. The default-configuration fix (50 MB cap in patched versions) means upgraded deployments are protected without any operator action.

No NVD CVSS vector was provided for this CVE, so risk must be inferred from the description and CWE. The attack surface is fully network-accessible (any reachable CXF endpoint accepting attachments), attack complexity is low (no special race condition or memory layout knowledge required - simply send an oversized payload), and no user interaction is needed. The impact is limited strictly to availability; there is no evidence of confidentiality or integrity exposure. EPSS data is absent, and the vulnerability is not in CISA KEV. While the severity of a pure DoS is moderate in isolation, the ease of exploitation and the broad enterprise deployment footprint of CXF elevate practical risk for operators who have not explicitly configured 'attachment-max-size'. Deployments behind authenticated proxies or rate-limiting gateways materially reduce risk. Authentication requirements for the underlying CXF service endpoint are deployment-specific and not confirmed from available data - operators must assess their own exposure.

An unauthenticated attacker (assuming a publicly exposed CXF endpoint) crafts a multipart SOAP or REST request containing an extremely large attachment - potentially hundreds of megabytes or gigabytes - and repeatedly submits it to a target CXF service. Without a default size cap, CXF attempts to buffer the entire payload in heap memory, causing the JVM to exhaust available memory and the service to become unresponsive or crash, denying access to legitimate users. No public exploit code has been identified at time of analysis, but the technique requires no specialized tooling beyond a standard HTTP client.