CVE-2026-50645

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 (DoS) vulnerability (CVE-2026-50645) has been identified in the AttachmentDeserializer class of the cxf-core module, which allows attackers to exhaust server memory and CPU by sending a multipart (MIME/MTOM/SwA) message whose attachment parts carry an unbounded number of headers.

Per OWASP: The Denial of Service (DoS) attack is focused on making a resource (site, application, server) unavailable for the purpose it was designed. There are many ways to make a service unavailable for legitimate users by manipulating network packets, programming, logical, or resources handling vulnerabilities, among others.

This issue affects all versions before 3.6.12, versions 4.0.0 through 4.1.6, and versions 4.2.0 through 4.2.1 of Apache CXF.

Details

Module Info

• Product: Apache CXF
• Affected packages: org.apache.cxf:cxf-core
• Affected versions: <3.6.12, >=4.0.0 <4.1.7, >=4.2.0 <4.2.2
• 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.12, 4.1.7, 4.2.2
  • NES for Apache CXF v3.5.13, v3.4.12

Vulnerability Info

This High-severity vulnerability is found in the org.apache.cxf:cxf-core package in all versions before 3.6.12, versions 4.0.0 through 4.1.6, and versions 4.2.0 through 4.2.1 of Apache CXF.

When a CXF endpoint receives a multipart message (for example an MTOM or SOAP with Attachments request), AttachmentDeserializer reads the headers of the root part and of every attachment part with its own MIME header parser. The parser reads lines from the request stream until it reaches an empty line and stores every header it finds in a map. The length of a single header line is capped by attachment-max-header-size, but nothing limits how many header lines one part may contain:

private Map<String, List<String>> loadPartHeaders(InputStream in) throws IOException {
    StringBuilder buffer = new StringBuilder(128);
    StringBuilder b = new StringBuilder(128);
    Map<String, List<String>> heads = new TreeMap<>(String.CASE_INSENSITIVE_ORDER);

    // loop until we hit the end or a null line
    while (readLine(in, b)) {
        // 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 {
            // if we have a line pending in the buffer, flush it
            if (buffer.length() > 0) {
                addHeaderLine(heads, buffer);
                buffer.setLength(0);
            }
            // add this to the accumulator
            buffer.append(b);
        }
    }
    // ...
    return heads;
}

private void addHeaderLine(Map<String, List<String>> heads, StringBuilder line) {
    // ...
    List<String> v = heads.computeIfAbsent(name, k -> new ArrayList<>(1));
    v.add(value);
}

Because the loop only stops at an empty line or end of stream, a remote attacker who can reach the endpoint can send a single part containing a very large number of short header lines, and each line becomes a new String held in the TreeMap. Every insertion also costs a case-insensitive tree lookup. The headers are parsed while the message is being deserialized, before it reaches the service implementation, so processing one such request can consume large amounts of heap and CPU, and a small number of concurrent requests can exhaust the JVM and make the service unavailable to legitimate users.

Mitigation

Only recent versions of Apache CXF receive community support. 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.