CVE-2026-107937 in CXF
Summary
by MITRE • 10/09/2026
In Apache CXF, the parser for multipart/MTOM attachment part headers did not fully enforce the configured attachment-max-header-size (default 300 characters) and attachment-headers-max-count (default 500) limits. The size limit was applied only to each physical line, not to a header value built from continuation lines or to the combined values of a repeated header. The count limit was checked against the number of distinct header names, not the total number of header lines. A remote, unauthenticated attacker could send a multipart request with very large folded or repeated part headers. The server would then allocate memory without bound, causing a denial of service. Users are recommended to upgrade to versions 4.2.4 or 4.1.9 or 3.6.13, which fix this issue.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/09/2026
The vulnerability in Apache CXF represents a critical flaw in the handling of multipart/MTOM attachment part headers, specifically within the parser logic that processes HTTP request metadata. This security defect stems from an incomplete enforcement of configured resource limits designed to prevent abuse and ensure system stability. The configuration parameters involved are attachment-max-header-size, which defaults to 300 characters, and attachment-headers-max-count, which defaults to 500 entries. These settings are intended to cap the memory footprint associated with parsing incoming multipart requests. However, the implementation failed to apply these constraints comprehensively across all valid HTTP header formats recognized by the protocol specification.
The technical root cause lies in how the parser interprets and aggregates header data according to RFC standards for HTTP message formatting. The size limit was strictly applied only to individual physical lines within a header block. It did not account for headers that span multiple lines through folding, where continuation lines are logically concatenated into a single logical header value by compliant parsers. Additionally, the implementation failed to sum the sizes of repeated instances of the same header name when they appear multiple times in a request. Consequently, an attacker could construct multipart requests containing extremely large folded headers or numerous repetitions of specific headers that individually stay within the per-line limit but collectively exceed the intended total size threshold.
Similarly, the count limit was evaluated against the number of distinct header names rather than the total quantity of header lines present in the request. This distinction allows an attacker to bypass the maximum entry restriction by repeating a small set of header names many times. Each repetition is counted as part of the same logical group or ignored entirely depending on the specific implementation details, but crucially, it does not increment the distinct name counter sufficiently to trigger the rejection mechanism. This oversight creates a significant gap between the intended security posture and the actual runtime behavior of the application server.
The operational impact of this vulnerability is severe, primarily manifesting as a denial of service condition for remote, unauthenticated attackers. By sending crafted multipart requests with oversized folded or repeated headers, an attacker can force the Apache CXF server to allocate memory without bound during the parsing phase. As the server attempts to process these malformed inputs, it consumes increasing amounts of system RAM until resources are exhausted. This leads to service degradation for legitimate users and potentially causes the application container to crash or become unresponsive. The attack requires no authentication, making it particularly dangerous in public-facing environments where such endpoints might be exposed directly to the internet.
From a classification perspective, this vulnerability aligns with CWE-787: Out-of-bounds Write if memory corruption occurs due to buffer handling errors, though more accurately it maps to CWE-400: Uncontrolled Resource Consumption because the primary vector is resource exhaustion via unbounded allocation. In terms of attack tactics, this falls under ATT&CK technique T1496: Resource Hijacking, specifically involving denial of service through computational or memory resource consumption. The lack of proper input validation and boundary checking for header aggregation constitutes a classic example of insufficient control over system resources when processing external data inputs.
To mitigate this risk, organizations running affected versions of Apache CXF must upgrade immediately to patched releases that correct the parsing logic. Specifically, users should migrate to version 4.2.4, version 4.1.9, or version 3.6.13, depending on their current deployment baseline. These updated versions implement strict enforcement of both size and count limits across all header variations, including folded continuations and repeated entries. Until the upgrade is performed, administrators may consider implementing web application firewall rules to inspect multipart requests for unusually large header blocks or excessive repetition patterns, although this serves only as a compensating control rather than a definitive fix. Regular patch management and adherence to vendor security advisories remain essential practices for maintaining the integrity of SOAP-based services built on Apache CXF.