CVE-2025-48913

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-2025-48913) 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 point the JNDI provider URL at an rmi:// or ldap:// server they control, potentially leading to code execution in the CXF process.

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 all versions of Apache CXF before 3.6.8, versions 4.0.0 through 4.0.8, and versions 4.1.0 through 4.1.2, 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.8, >=4.0.0 <4.0.9, >=4.1.0 <4.1.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.8, 4.0.9, 4.1.3
• NES for Apache CXF v3.4.12 and v3.5.13

Vulnerability Info

This Critical-severity vulnerability is found in the org.apache.cxf:cxf-rt-transports-jms package in all versions before 3.6.8, 4.0.0 through 4.0.8, and 4.1.0 through 4.1.2 of Apache CXF.

The CXF JMS transport resolves connection factories and destinations through JNDI. The JNDI environment is built from endpoint configuration: the jndiURL, jndiInitialContextFactory, and arbitrary jndi-* parameters of a jms: address, or the jndiEnvironment properties set on JMSConfiguration. JMSConfigFactory copies these values straight into the environment, including Context.PROVIDER_URL:

public static Properties getInitialContextEnv(JMSEndpoint endpoint) {
    Properties env = new Properties();
    if (endpoint.getJndiInitialContextFactory() != null) {
        env.put(Context.INITIAL_CONTEXT_FACTORY, endpoint.getJndiInitialContextFactory());
    }
    if (endpoint.getJndiURL() != null) {
        env.put(Context.PROVIDER_URL, endpoint.getJndiURL());
    }
    for (Map.Entry<String, String> ent : endpoint.getJndiParameters().entrySet()) {
        env.put(ent.getKey(), ent.getValue());
    }
    ...
    return env;
}

The environment is then handed to JndiHelper, which stores it without any validation and opens an InitialContext against whatever provider URL it contains:

public JndiHelper(Properties environment) {
    this.environment = environment;
}

@SuppressWarnings("unchecked")
public <T> T lookup(final String name, Class<T> requiredType) throws NamingException {
    Context ctx = new InitialContext(this.environment);
    try { // NOPMD - UseTryWithResources
        Object located = ctx.lookup(name);
        ...
        return (T)located;
    } finally {
        ResourceCloser.close(ctx);
    }
}

Nothing restricts the scheme of the provider URL to a JMS broker protocol. If an attacker can control the JMS configuration (for example, an application that lets users define or edit JMS endpoint addresses), they can set the provider URL to an rmi:// or ldap:// endpoint under their control. The lookup then contacts the attacker's naming service, which can return a malicious reference or serialized object that the JVM resolves, a classic JNDI injection that can end in arbitrary code execution. This is reached on every JNDI lookup the transport performs, including the connection factory lookup in JMSConfiguration and destination resolution through JMSDestinationResolver.

Mitigation

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

• M Bhatt from OWASP GenAI Security Project (finder)
• Blake Gatto from Shrewd Research (finder)