Apache CXF EUVD-2026-95704

Requires a reachable Apache CXF web-service endpoint that parses attacker-supplied XML and builds a DOM - specifically the SAAJ or WS-Security processing paths - running a version prior to 4.2.4, 4.1.9, or 3.6.13. The vendor explicitly scopes the DoS to deployments where 'no request size limit was configured,' so the primary limiting factor is the presence of any upstream or container-level request-size cap (reverse proxy, API gateway, or servlet max-post-size), which largely neutralizes the issue. No authentication is inherently required by the parsing flaw itself, but exposure depends on whether the vulnerable endpoint is publicly reachable and unauthenticated in a given deployment.

No CVSS vector, EPSS score, KEV listing, or POC is provided in the input, so quantitative exploitation signals are entirely absent and risk must be inferred from the description alone. The flaw is a memory/CPU exhaustion denial-of-service in Apache CXF's StaxUtils: by default no cap existed on XML element count or character count, so an oversized XML body consumed excessive resources during parsing - especially where CXF builds a DOM (SAAJ or WS-Security). Based on the description this is a network-reachable, low-complexity, availability-only issue (my independent assessment: AV:N/AC:L/PR:N/UI:N/A:H, approximately 7.5), which would normally rate HIGH. However, real-world risk is tempered by a key limiting condition stated in the advisory itself: the DoS occurs 'when no request size limit was configured,' so deployments fronted by a reverse proxy, gateway, or servlet container request-size limit are substantially less exposed. There is no confidentiality or integrity impact. Exploitation status: no public exploit identified at time of analysis, and no evidence of active exploitation. Net assessment: a legitimate availability risk for internet-facing CXF SOAP/WS-Security endpoints lacking size limits, but not an urgent actively-exploited priority - patch in a normal cycle and verify upstream size limits.

An attacker sends a single very large XML/SOAP request (millions of elements or a multi-hundred-megabyte document) to a CXF-based web service endpoint that builds a DOM for SAAJ or WS-Security processing. With no element-count or character limit and no request-size limit configured, parsing exhausts heap and CPU, degrading or crashing the service for legitimate users. No public exploit is identified at time of analysis, though crafting such a payload is trivial.