CVE-2026-50632

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-50632) has been identified in the Apache CXF JMS transport (cxf-rt-transports-jms), which allows attackers who can supply or influence the JMS configuration of a CXF endpoint to direct a JNDI lookup to a naming service they control, potentially leading to code execution in the CXF process. This is a further incomplete fix for CVE-2026-44417: the provider URL allow list does not cover the JNDI names being looked up, or the JNDI environment properties that choose object and URL context factories.

Per OWASP: Code Injection is the general term for attack types which consist of injecting code that is then interpreted/executed by the application. This type of attack exploits poor handling of untrusted data.

This issue affects all versions of Apache CXF before 3.6.12, versions 4.0.0 through 4.1.6, and versions 4.2.0 through 4.2.1, including the End-of-Life 3.4.x and 3.5.x lines of Apache CXF.

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.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-rt-transports-jms
• Package manager: Maven
• Fixed in:
  
  • OSS Apache CXF 3.6.12, 4.1.7, 4.2.2
  • NES for Apache CXF v3.4.12 and v3.5.13

Vulnerability Info

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

The CXF JMS transport performs JNDI lookups on names taken from endpoint configuration. The connection factory, destination, and reply destination names are resolved through JndiHelper, and the jndiTransactionManagerName is looked up by JMSConfigFactory in a new default InitialContext, with no check on the name:

private static TransactionManager getTransactionManagerFromJndi(String transactionManagerJndiName) {
    if (transactionManagerJndiName == null) {
        return null;
    }
    try {
        InitialContext ictx = new InitialContext();
        return (TransactionManager)ictx.lookup(transactionManagerJndiName);
    } catch (NamingException e) {
        throw new IllegalArgumentException("Transaction Manager " + transactionManagerJndiName
                                           + " not found in jndi");
    }
}

JNDI resolves a name written as a URL, such as an ldap:// or rmi:// name, through the naming provider for that URL scheme instead of the configured provider, so a restriction on Context.PROVIDER_URL does not apply to it. The JNDI environment that JMSConfigFactory builds from the jndi-* parameters of a jms: address is also passed to InitialContext unfiltered, so it can set java.naming.factory.object, java.naming.factory.state, or java.naming.factory.url.pkgs and change which factory classes take part in every lookup. On Java 8, the JDK's built-in CORBA naming provider also resolves remote names that do not contain ://.

If an attacker can control the JMS configuration of a CXF endpoint, a URL-form name makes the lookup contact a naming service under the attacker's control, and the factory properties change how the returned reference is turned into an object. The naming service can return a malicious reference or serialized object that the JVM resolves, a JNDI injection that can end in arbitrary code execution in the CXF process. Deployments that do not allow untrusted users to configure JMS for Apache CXF are not exposed.

Mitigation

Only recent versions of Apache CXF are community-supported. The affected 3.4.x and 3.5.x 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

• Venkatraman Kumar from Securin (finder)