CVE-2010-0738

What is Red Hat JBoss and the JMX-Console?

Red Hat JBoss Enterprise Application Platform (EAP) — formerly JBoss AS (Application Server) — is an open-source Java EE application server widely deployed in enterprise environments for hosting Java web applications. JBoss includes a built-in Java Management Extensions (JMX) Console (/jmx-console) for administrative operations — deploying and undeploying applications, inspecting MBeans, triggering garbage collection, and managing application server configuration. In properly secured deployments, the JMX-Console is restricted to administrators. However, misconfigurations and application server vulnerabilities frequently left it exposed, making it one of the most exploited enterprise Java attack surfaces from 2010 onward.

Overview

CVE-2010-0738 is a medium-severity authentication bypass vulnerability (CVSS 5.3) in the JBoss AS JMX-Console web application. The JMX-Console's access control checked only GET and POST HTTP methods — but JBoss would process requests sent with any other HTTP method (such as HEAD, PUT, DELETE, or custom methods) without enforcing the access restrictions. An unauthenticated remote attacker could use this bypass to interact with the JMX-Console and its administrative functions. The ransomwareUse: true designation reflects documented use in ransomware pre-deployment campaigns. CISA added to KEV in May 2022.

Affected Versions

Technical Details

The vulnerability (authentication bypass via HTTP verb tampering) exists in the JMX-Console web application's access control filter. The JBoss deployment configured the JMX-Console to require authentication for GET and POST requests — the two standard HTTP methods used by browsers. However, the JBoss HTTP server processed other HTTP verbs (HEAD, OPTIONS, TRACE, PUT, etc.) and passed them to the same JMX-Console handlers without applying the authentication filter.

An attacker could:

1. Send an HTTP request to /jmx-console/HtmlAdaptor using a non-GET/POST method (e.g., HEAD)
2. The authentication check was not applied for this verb
3. The JMX-Console processed the request, exposing JMX MBean operations to the unauthenticated attacker

While the CVSS 5.3 score reflects "Integrity: Low" impact, this significantly understates the practical risk. Through the JMX-Console, attackers could:

• Deploy WAR files: Use the MainDeployer or DeploymentManager MBeans to deploy a malicious Java web application (WAR file) to the server
• Execute arbitrary code: A deployed WAR containing a web shell or reverse shell provided full code execution on the server
• Access all server resources: The JBoss process typically had access to database credentials, application keys, and internal network resources

Discovery

Discovered by security researchers analyzing JBoss access control mechanisms. The issue was publicly disclosed through security mailing lists and quickly weaponized. This vulnerability, combined with CVE-2010-1428 (web-console information disclosure), gave attackers a comprehensive toolkit for attacking JBoss deployments.

Exploitation Context

JBoss JMX-Console attacks were heavily used in ransomware and cryptomining campaigns:

• Ransomware deployment: Threat actors scanning for exposed JMX-Consoles used the verb bypass to deploy WAR-based web shells, then used those shells for network reconnaissance before deploying ransomware. The ransomwareUse: true flag reflects this documented pattern.
• Mass scanning: JBoss servers listening on port 8080 with exposed /jmx-console paths were routinely identified through internet scanning. The combination of CVE-2010-0738 and CVE-2010-1428 allowed attackers to take complete control of any exposed JBoss server.
• Long-tail legacy deployments: JBoss AS 4.x and JBoss EAP 4.3 were deployed throughout the 2005–2012 era in enterprise Java shops. Many of these servers remained in production years later, particularly where applications couldn't be easily migrated.
• Supply chain pivot: A compromised JBoss server typically had connectivity to internal databases and enterprise applications, making it a valuable pivot point for lateral movement.

Remediation

1. Restrict JMX-Console access: Apply JBoss security configurations to require authentication for ALL HTTP methods to /jmx-console, not just GET and POST.
2. Remove JMX-Console from production: In production deployments, the JMX-Console should be completely removed or disabled — use JBoss CLI or management APIs for administration instead.
3. Apply Red Hat Security Advisory: Update JBoss EAP to the version specified in the Red Hat advisory that addresses CVE-2010-0738.
4. Network firewall: Block external access to JBoss management ports (8080, 9990, 4444) at the network perimeter.
5. Upgrade JBoss: JBoss AS 4.x and JBoss EAP 4.3 are end-of-life. Upgrade to JBoss EAP 7 or WildFly (current JBoss community server).