CVE-2026-108039 in CXF
Summary
by MITRE • 10/09/2026
By default, StaxUtils placed no limit on the total number of elements or the total number of characters in an XML document. A very large request could therefore use a lot of memory and CPU during parsing, especially where CXF builds a DOM from the input (for example SAAJ or WS-Security), and could cause a denial of service when no request size limit was configured. Both limits now have defaults: the maximum element count is 100 × maxChildElements (5,000,000 by default), and the maximum document size is 256M characters. Applications that process larger documents can raise the limits with the org.apache.cxf.stax.maxElementCount and org.apache.cxf.stax.maxXMLCharacters properties. Users are recommended to upgrade to versions 4.2.4 or 4.1.9 or 3.6.13, which fix this issue.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/09/2026
The vulnerability described involves a resource exhaustion flaw within the StaxUtils component of Apache CXF, specifically related to XML parsing limits. By default, prior to the remediation, there was no restriction on either the total number of elements or the total character count in an incoming XML document. This absence of constraints allowed attackers to craft extremely large XML payloads that could consume excessive memory and CPU resources during the parsing process. The risk is particularly acute when CXF constructs a Document Object Model from the input data, such as in scenarios involving SAAJ or WS-Security implementations, where the entire structure must be held in memory simultaneously.
This lack of enforcement on document size effectively creates an opportunity for Denial of Service attacks. An adversary can send a request with a massive XML body that forces the server to allocate significant system resources to parse and process it. If no external request size limit is configured at the network or application gateway level, this internal parsing behavior becomes the primary vector for resource exhaustion. The resulting spike in memory usage and CPU consumption can degrade service availability for legitimate users or cause the application to crash entirely, leading to a complete denial of service condition.
From a classification perspective, this issue aligns with CWE-400, which covers Uncontrolled Resource Consumption, as well as CWE-787, Out-of-bounds Write, in contexts where excessive memory allocation might lead to buffer overflows or heap corruption depending on the underlying implementation details. In terms of attack patterns, it corresponds to MITRE ATT&CK technique T1496, Resource Hijacking, specifically under sub-technique for Denial of Service via resource exhaustion. The vulnerability highlights a common pitfall in XML processing libraries where convenience features like automatic DOM building are enabled without corresponding safeguards against maliciously large inputs.
To mitigate this risk, the default configuration has been updated to impose strict limits on both element count and document size. The maximum number of elements is now capped at 100 times the value of maxChildElements, which defaults to five million elements. Additionally, the maximum character limit for a single XML document is set to two hundred fifty-six megabytes. These thresholds are designed to balance functionality with security, preventing most abuse scenarios while still allowing legitimate large documents to be processed. Applications that require handling payloads larger than these defaults can adjust the limits by setting the org.apache.cxf.stax.maxElementCount and org.apache.cxf.stax.maxXMLCharacters system properties accordingly.
Organizations using affected versions of Apache CXF are strongly advised to upgrade immediately to version 4.2.4, 4.1.9, or 3.6.13, which contain the necessary patches for this issue. For environments where legacy applications depend on processing exceptionally large XML structures that exceed the new defaults, administrators should carefully tune the configuration properties mentioned above rather than reverting to unlimited parsing. It is also recommended to implement defense-in-depth strategies by configuring web servers or API gateways to enforce request size limits at the network layer, providing an additional barrier against oversized payloads before they reach the application server for processing.