JBoss
Enumeration and Exploitation Techniques
Check for exposed legacy and current management endpoints, including /admin-console/, /jmx-console/, /management/, /web-console/, /web-console/ServerInfo.jsp, and /status?full=true. The available paths vary by JBoss generation and configuration. Legacy JBoss deployments may expose an HTML JMX console or invoker servlets; Red Hat’s security guidance recommends restricting these administrative access points.[1]
- Test authentication rather than assuming a default password. If a management interface is exposed, enumerate its version, enabled roles, and accessible operations before attempting any authenticated checks.
- On legacy installations, also check
/web-console/Invoker,/invoker/JMXInvokerServlet,/restricted/JMXInvokerServlet, and/invoker/EJBInvokerServlet. These invokers can transport serialized invocations to MBeans or EJB/JNDI services, so an exposed or weakly protected endpoint may provide powerful management operations.[1]
The clusterd toolkit and Metasploit’s auxiliary/scanner/http/jboss_vulnscan module automate checks for exposed JBoss interfaces and known deployment weaknesses.[2][3]
Exploitation Resources
JexBoss can identify and validate several known JBoss and Java deserialization issues. Use active exploitation only with explicit authorization and verify the detected product/version before selecting a check.[4]
Finding Vulnerable Targets
Search engines may reveal inadvertently indexed management endpoints. For assets within the authorized scope, one possible query is inurl:status EJBInvokerServlet.