Apache CXF JMS Deserialization Flaw Allows Unauthenticated RCE

Executive Summary

The Apache Software Foundation has disclosed CVE-2026-66909, a critical Java deserialization vulnerability in Apache CXF's JMS transport. The flaw allows any attacker who can place a message on the service's JMS destination to submit a malicious serialized Java object, leading to denial of service unconditionally or remote code execution when a gadget chain is present on the classpath.

CVSS Score: 9.8 (Critical) CVSS Vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

This vulnerability was disclosed on August 6, 2026 by Colm O hEigeartaigh of the Apache CXF security team via the oss-security mailing list, as part of a larger batch of CXF advisories.

Vulnerability Overview

Root Cause

Apache CXF's JMS transport deserializes the body of any inbound JMS ObjectMessage using native Java deserialization (ObjectInputStream.readObject()) with no type restrictions — no allowlist, no denylist, and no ObjectInputFilter. This is a textbook CWE-502: Deserialization of Untrusted Data flaw.

Attack Chain

1. Attacker identifies service exposing an Apache CXF JMS endpoint
2. Places a crafted JMS ObjectMessage on the service's JMS destination
3. Apache CXF deserializes the ObjectMessage body with no type checks
4. A deserialization gadget chain on the classpath is triggered
5. Arbitrary OS commands execute with application server privileges

DoS is unconditional — any malformed serialized object crashes the deserializer. RCE is conditional on a gadget chain being present (e.g. Apache Commons Collections, Spring Framework, or similar libraries commonly found in enterprise Java deployments).

Technical Details

Affected Versions

Why JMS ObjectMessage Is High-Risk

JMS ObjectMessage is a message type that carries a fully serialized Java object as its body. Unlike TextMessage or BytesMessage, consuming an ObjectMessage requires calling getObject(), which internally invokes Java's native deserialization. Without a type filter, any class on the classpath can be instantiated through a gadget chain during deserialization — even classes the application never intended to use.

Common Gadget Chain Libraries

If any of the following are on your classpath alongside an unpatched CXF installation, RCE is likely achievable:

• Apache Commons Collections (versions 3.x / 4.x)
• Spring Framework (certain versions)
• Apache Commons BeanUtils
• SnakeYAML, Groovy, ROME feed parser

Detection

Identify Vulnerable Deployments

# Check your CXF version in Maven dependencies
mvn dependency:tree | grep cxf
 
# Check JAR files directly
find /opt /usr/local /app -name "cxf-core-*.jar" 2>/dev/null
 
# Check for JMS transport configuration
grep -r "JMSConduit\|jms://" src/ config/ --include="*.xml" --include="*.properties"

Log Indicators of Exploitation

# Unexpected ClassCastException or ClassNotFoundException during message processing
# OutOfMemoryError or infinite loops triggered during deserialization
# Unusual JMS consumer thread crashes coinciding with inbound message activity

SIEM / IDS Considerations

JMS is a broker-level protocol — traditional network signatures are difficult to apply. Detection should focus on:

• Application-layer logs for unexpected deserialization exceptions
• Behavioral anomalies: new processes spawned from the JMS consumer thread
• JVM crash dumps or heap dumps generated unexpectedly

Immediate Remediation

Option 1: Upgrade Apache CXF (Recommended)

Upgrade to the fixed versions:

<!-- Maven pom.xml — choose the branch matching your deployment -->
<dependency>
    <groupId>org.apache.cxf</groupId>
    <artifactId>cxf-core</artifactId>
    <version>4.2.3</version><!-- or 4.1.8 or 3.6.12 -->
</dependency>

The patch disables ObjectMessage deserialization by default. A configuration switch can re-enable it, but only do so when the JMS destination is fed exclusively by fully trusted producers inside a controlled network segment.

Option 2: Disable ObjectMessage Handling

If upgrading immediately is not possible, configure CXF to reject ObjectMessage at the transport level:

<!-- CXF JMS endpoint configuration -->
<jms:conduit name="{ns}ServicePort.jms-conduit">
    <jms:clientConfig>
        <!-- Reject ObjectMessage types entirely -->
        <jms:jmsClientConfig messageType="text"/>
    </jms:clientConfig>
</jms:conduit>

Option 3: JVM-Level Deserialization Filter (Java 9+)

Apply a JVM-wide deserialization filter as an additional defense layer:

# Add to JVM startup arguments
-Djdk.serialFilter="!*"
 
# Or allow only specific safe classes
-Djdk.serialFilter="com.example.safepackage.*;!*"

Option 4: Network Segmentation

Restrict who can publish to JMS destinations serviced by CXF. Only trusted internal producers should have write access to CXF-consumed JMS queues or topics.

Related CVEs in This Advisory Batch

This CVE was disclosed alongside several other Apache CXF vulnerabilities on August 6, 2026:

Organizations running Apache CXF should treat the full advisory batch as a single patching effort.

References

• Apache CXF Security Advisories
• NVD — CVE-2026-66909
• oss-security Mailing List Disclosure
• CWE-502: Deserialization of Untrusted Data

Related Reading

• Apache CXF OAuth2 Scope Injection — CVE-2026-61466
• Apache Struts Critical RCE via OGNL Injection Returns