CVE-2026-107937

Overview

Apache CXF is an open-source services framework, maintained by the Apache Software Foundation, for building and consuming web services in Java. It implements the JAX-WS and JAX-RS APIs and supports SOAP, the WS-* standards, RESTful HTTP, and OAuth 2.0 over transports such as HTTP and JMS. Its modules are published as Maven artifacts under org.apache.cxf.

A denial of service vulnerability (CVE-2026-107937) has been identified in the multipart/MTOM attachment parser of Apache CXF, which allows remote, unauthenticated attackers to bypass the configured attachment header size and count limits. A request carrying very large folded or repeated part headers makes the server allocate memory without bound, which can exhaust memory and make the service unavailable.

Per OWASP: The Denial of Service (DoS) attack is focused on making a resource (site, application, server) unavailable for the purpose it was designed.

This issue affects multiple versions of Apache CXF.

Details

Module Info

• Product: Apache CXF
• Affected packages: org.apache.cxf:cxf-core
• Affected versions: <3.6.13, >=4.0.0 <4.1.9, >=4.2.0 <4.2.4
• GitHub repository: https://github.com/apache/cxf
• Published packages: https://central.sonatype.com/artifact/org.apache.cxf/cxf-core
• Package manager: Maven
• Fixed in:
  • OSS Apache CXF 3.6.13, 4.1.9, 4.2.4
  • NES for Apache CXF v3.4.13, v3.5.14

Vulnerability Info

This Low-severity vulnerability is found in the org.apache.cxf:cxf-core package in multiple versions of Apache CXF. When CXF reads a multipart or MTOM message, AttachmentDeserializerUtil.loadPartHeaders collects the headers of each attachment part. Two configurable limits are meant to bound this work: attachment-max-header-size (default 300 characters) and attachment-headers-max-count (default 500).

The size limit is only enforced inside readLine, against a single physical line. A line that starts with a space or tab is a header continuation, and it is appended to the pending header with no further check:

while (readLine(in, b, maxHeaderLength)) {
    // lines beginning with white space get special handling
    char c = b.charAt(0);
    if (c == ' ' || c == '\t') {
        if (buffer.length() != 0) {
            // preserve the line break and append the continuation
            buffer.append("\r\n");
            buffer.append(b);
        }
    } else {
        ...
    }
}

Each continuation line can be up to the per-line limit, so an attacker can fold one header across an unlimited number of lines and grow buffer without bound.

Where the count limit is present, it is checked in addHeaderLine, but against heads.size(), which is the number of distinct header names in the map. A repeated header name adds another value to the existing list, and nothing bounds the length of that list or the combined size of its values:

if (heads.size() >= maxHeadersCount) {
    throw new IOException("The attachment contains more headers than are permitted");
}
List<String> v = heads.computeIfAbsent(name, k -> new ArrayList<>(1));
v.add(value);

A remote, unauthenticated client that can post a multipart/MTOM request to a CXF endpoint can therefore send a part with very large folded headers, or the same header name repeated many times. The parser keeps every byte in memory, and the server allocates memory without bound until it runs out, denying service to legitimate users.

Mitigation

Only recent versions of Apache CXF are community-supported. Older lines are End-of-Life and will not receive public updates to address this issue.

Users of the affected components should apply one of the following mitigations:

• Upgrade to a currently supported Apache CXF release line (3.6.x or later) that contains the fix.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

Credits

• Mike Read (finder)