CVE-2026-66909

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 Remote Code Execution (RCE) vulnerability (CVE-2026-66909) has been identified in the Apache CXF JMS transport, which allows attackers who can place a message on a service's JMS destination (or on a client's reply destination) to submit a malicious serialized Java object in a JMS ObjectMessage. CXF deserializes that object with native Java deserialization and no type restrictions, leading to denial of service or, when a suitable gadget class is on the classpath, arbitrary code execution.

Per OWASP: Data which is untrusted cannot be trusted to be well formed. Malformed data or unexpected data could be used to abuse application logic, deny service, or execute arbitrary code, when deserialized.

This issue affects all versions prior to 3.6.12, versions 4.0.0 through 4.1.7, and versions 4.2.0 through 4.2.2 of Apache CXF, including the End-of-Life 3.5.x line.

Details

Module Info

• Product: Apache CXF
• Affected packages: org.apache.cxf:cxf-rt-transports-jms
• Affected versions: <3.6.12, >=4.0.0 <4.1.8, >=4.2.0 <4.2.3
• GitHub repository: https://github.com/apache/cxf
• Published packages: https://central.sonatype.com/artifact/org.apache.cxf/cxf-rt-transports-jms
• Package manager: Maven
• Fixed in:
• OSS Apache CXF 3.6.12, 4.1.8, 4.2.3
• NES for Apache CXF v3.5.13, v3.4.12

Vulnerability Info

This Critical-severity vulnerability is found in the org.apache.cxf:cxf-rt-transports-jms package in all versions prior to 3.6.12, 4.0.0 through 4.1.7, and 4.2.0 through 4.2.2 of Apache CXF.

Every inbound JMS message handled by the CXF JMS transport is converted into a CXF message by JMSMessageUtils.asCXFMessage. This path is used both by JMSDestination for incoming service requests and by JMSConduit for replies received by JMS clients. The payload is extracted with JMSMessageConverter.fromMessage:

// org.apache.cxf.transport.jms.JMSMessageUtils
private static void retrieveAndSetPayload(org.apache.cxf.message.Message inMessage, Message message)
    throws UnsupportedEncodingException, JMSException {
    final String messageType;
    Object converted = new JMSMessageConverter().fromMessage(message);
    ...
}

// org.apache.cxf.transport.jms.util.JMSMessageConverter
public Object fromMessage(Message message) throws JMSException {
    if (message instanceof TextMessage) {
        return ((TextMessage)message).getText();
    } else if (message instanceof BytesMessage) {
        ...
    } else if (message instanceof ObjectMessage) {
        return ((ObjectMessage)message).getObject();
    } else if (message instanceof StreamMessage) {
        ...
    }
}

The message type is chosen by whoever sends the message, not by the service configuration. If an attacker sends an ObjectMessage instead of the expected TextMessage or BytesMessage, ObjectMessage.getObject() runs native Java deserialization on the attacker-supplied bytes before CXF looks at the result. No class allow-list or other type check is applied, so any serializable class on the application classpath can be instantiated and its deserialization logic run. With a known gadget chain on the classpath this results in remote code execution; otherwise, crafted object graphs can still exhaust CPU or memory. Exploitation requires only the ability to publish to the JMS queue or topic the CXF endpoint listens on, or to the reply destination a CXF JMS client reads from.

This vulnerability was introduced in 2006 with Apache CXF 2.0-incubator-M1.

Mitigation

Only recent versions of Apache CXF are community-supported. The 3.5.x line was already End-of-Life when this CVE was published 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

• n0mi1k (finder)