CVE-2026-44417

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-44417) has been identified in the JMS transport's message listener container, which allows attackers who can supply JMS configuration to point the JNDI provider URL at an attacker-controlled rmi:// or ldap:// server and execute arbitrary code. This is an incomplete fix for CVE-2025-48913: the protocol allow list added to the JNDI helper was never applied to the separate JNDI context that the listener container creates.

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 versions prior to 3.6.11, 4.0.0 through 4.1.5, and 4.2.0 of Apache CXF.

Details

Module Info

• Product: Apache CXF
• Affected packages: org.apache.cxf:cxf-rt-transports-jms
• Affected versions: <3.6.11, >=4.0.0 <4.1.6, >=4.2.0 <4.2.1
• 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.11, 4.1.6, 4.2.1
• 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 versions prior to 3.6.11, 4.0.0 through 4.1.5, and 4.2.0 of Apache CXF.

When a JMS destination starts, JMSDestination hands the endpoint's configured JNDI environment (jndiEnvironment, including java.naming.provider.url) to the message listener container. The polling listener container then calls createInitialContext() at the start of every poll loop iteration, and that method builds a JNDI InitialContext directly from the configured properties without any check on the provider URL:

// JMSDestination.createTargetDestinationListener()
container.setJndiEnvironment(jmsConfig.getJndiEnvironment());
container.start();

// PollingMessageListenerContainer.Poller.run()
try (ResourceCloser closer = new ResourceCloser()) {
    closer.register(createInitialContext());
    ...

// AbstractMessageListenerContainer
public InitialContext createInitialContext() {
    if (jndiEnvironment != null) {
        try {
            return new InitialContext(this.jndiEnvironment);
        } catch (NamingException e) {
            LOG.log(Level.SEVERE, "Could not expose JNDI environment to JMS thread context", e);
        }
    }
    return null;
}

The remediation for CVE-2025-48913 restricted Context.PROVIDER_URL to an allow list of JMS broker schemes, but only inside JndiHelper. Because AbstractMessageListenerContainer constructs its own InitialContext rather than going through JndiHelper, an attacker who is able to control the JMS configuration of a CXF endpoint can still set the provider URL to an rmi:// or ldap:// address under their control. Once the listener container uses that context, the attacker's server can return a malicious reference or serialized object, leading to 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

• Exploit Intel (finder)