Does CVE-2014-3518 affect JBoss products?

Solution Unverified - Updated -


  • Red Hat JBoss Enterprise Application Platform (EAP)
    • 5.x
  • Red Hat JBoss BRMS (BRMS)
    • 5.x
  • Red Hat JBoss SOA Platform (SOA-P)
    • 5.x
  • Red Hat JBoss Portal (JPP)
    • 5.x


  • JBoss Application Server 5 and supported Red Hat JBoss 5.x products contain JBoss Remoting, which includes a partial implementation of the JMX remoting specification JSR 160.

  • This implementation is provided in jmx-remoting.sar, which is deployed by default in unsupported community releases of JBoss Application Server 5.x. This implementation does not implement security as defined in JSR 160, and therefore does not apply any authentication or authorization constraints. A remote attacker could use this to potentially execute malicious code on a vulnerable server. This flaw is identified by CVE-2014-3518.

  • Does this affect Jboss Products?

  • Does the JBoss Remoting Vulnerability CVE-2014-3518 affect Red Hat JBoss EAP 5 if the jmx-remoting.sar is not deployed in the Jboss instance?

  • Is the vulnerability CVE-2014-3518 specifically related to the Mail service?

  • Multiple Red Hat JBoss Products Remote Arbitrary Code Execution Vulnerability. RedHat CVE-2014-3518 reported. Kindly suggest.


  • By default, all supported Red Hat JBoss 5.x products are not affected. These products will only be vulnerable if JMX remoting is enabled by manually deploying jmx-remoting.sar from thejboss-as/docs/examples directory. Unsupported community releases of JBoss Application Server 5.x are affected by default. All users of the standalone JBoss Remoting project are also affected.

  • If your server is affected, you should undeploy jmx-remoting.sar if JMX remoting is not required by your applications. If it is required, you should secure JMX remoting.

Configuring with password access files security

# Enable the jconsole agent locally

# Tell JBossAS to use the platform MBean server
JAVA_OPTS="$JAVA_OPTS -Djboss.platform.mbeanserver"

# Make the platform MBean server able to work with JBossAS MBeans

# Set the port

# Enable security using user/pass in properties file
  • Unless it is set, defaults to $JAVA_HOME/jre/lib/management/jmxremote.access and defaults to $JAVA_HOME/jre/lib/management/jmxremote.password

  • The usernames and passwords are defined injmxremote.password (there is a template in $JAVA_HOME/jre/lib/management/jmxremote.password.template)

  • For example, adding an admin user with a password of redhat, and a user named monitor with password jboss, would be like:

admin redhat
monitor jboss
  • The users's roles are defined in jmxremote.access, there are two roles readonly and readwrite, so we could allow user monitor to only read mbeans and allow user admin to read and write by:
admin readwrite
monitor readonly
  • Then test the service connectivity: jmx:rmi:///jndi/rmi://
import java.util.Map;
import java.util.HashMap;

    // this is the port that you configure in $JBOSS_HOME/bin/run.conf
    int portNum = 19988;

    // the hostName should be set to the ip / hostname that the JBoss you want to call is listening upon
    String serviceURL = "service:jmx:rmi:///jndi/rmi://" + hostName + ":" + portNum +  "/jmxrmi";

    // Create a JMXServiceURL
    JMXServiceURL u = new JMXServiceURL(serviceURL);

    // If you have authentication enabled, configure the username / password credentials
    Map environment = new HashMap(1);
    String[] credentials = {user, pass};
    environment.put(JMXConnector.CREDENTIALS, credentials);

    // connect to the JMXServiceURL using the given environment properties (If you have authentication disabled, you can remove the environment) 
    JMXConnector c = JMXConnectorFactory.connect(u, environment);

    // Get the MBeanServer connection which has the API to get and call the MBeans
    MBeanServerConnection server = c.getMBeanServerConnection();

    // Test by getting the number of mbeans
    System.out.println("MBean Count: " + server.getMBeanCount());

    // Cleanup 
    if(c != null) {

Diagnostic Steps

  • To determine whether your system is vulnerable, use the Red Hat access labs detector tool.
    If you have jmx-remoting.sar enabled and affected, you should see some lines printed out like this:1
$ java -jar CVE-2014-3518-SAFE.jar -H -r 19988
[CVE-2014-3518] Testing RMI via remote connections ... 
[CVE-2014-3518] Testing with host:: rmi-port::19988
[CVE-2014-3518] Testing mail service ... 
[CVE-2014-3518] jboss:service=Mail.getJNDIName returned java:/Mail
[CVE-2014-3518] MailService returned as expected, VULNERABLE
  • By default on JBoss EAP 5.x, if jmx-remoting.sar is not configured, you will see:
$ java -jar CVE-2014-3518-SAFE.jar -H -r 1090
[CVE-2014-3518] Testing RMI via remote connections ... 
[CVE-2014-3518] Testing with host:: rmi-port::1090
[CVE-2014-3518] RMI Server returned unknown host, poisoning cache to try again ... 
[CVE-2014-3518] Could not make an RMI connection, skipping. Reason: Failed to retrieve RMIServer stub: javax.naming.ServiceUnavailableException [Root exception is java.rmi.ConnectException: Connection refused to host:; nested exception is: Connection refused]

  1. Using the JBoss Remoting implementation as provided within the jmx-remoting.sar, or any implementation that was based on those JARs, is affected by this vulnerability. The mail service, which is tested by CVE-2014-3518-SAFE.jar above, is just one of many services that could be used by an unauthenticated attacker, circumventing any other security. 

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.