Skip to main content
protocols.pageprotocols.page
8180

Port 8180 – JBoss / WildFly HTTP

TCP

Port 8180 is used by JBoss/WildFly application server instances when port 8080 is occupied (port offset configuration). JBoss uses port offsets to run multiple instances on one host – offset 100 shifts 8080 to 8180, 9990 to 10090, etc. Same security concerns as any Java EE application server.

Port Number

8180

Protocol

TCP

Service

JBoss Application Server HTTP

Range

IANA Registered (1024–49151)

Description

JBoss and WildFly use socket binding port offsets to run multiple application server instances on a single host. The default HTTP port is 8080; with offset=100, it becomes 8180. This pattern extends to all server ports – management (9990+100=10090), AJP (8009+100=8109), etc. Port 8180 on a server typically indicates a second JBoss/WildFly instance. Apply the same security practices as the primary instance: disable the management console on public interfaces, deploy only necessary applications, keep the server patched against deserialization vulnerabilities, and use a reverse proxy with TLS for client-facing traffic.

Security risks

  • 1CVE-2017-12149 (CVSS 9.8): JBoss Application Server RCE via Java deserialization in HttpInvoker (ReadOnlyAccessFilter bypass). Unauthenticated attacker sends serialized payload to /invoker/readonly on port 8180, executing arbitrary code as the JBoss user. Actively exploited in the wild.
  • 2CVE-2010-0738: JBoss JMXInvokerServlet unauthenticated access – allows deploying arbitrary WAR files (webshells) via /jmx-console and /web-console without credentials. Affected JBoss 4.x/5.x instances still found on legacy systems.
  • 3Management console exposure: JBoss/WildFly management (offset port 10090 = 9990+100) may be accessible without auth on older versions. Admin console enables deploying applications, changing datasources, and reading server configuration including JDBC passwords.
  • 4Deserialization in multiple endpoints: JBoss exposes multiple Java serialization endpoints (/invoker/JMXInvokerServlet, /invoker/EJBInvokerServlet) that accept arbitrary serialized objects. Tools like ysoserial generate RCE payloads for known gadget chains.

Firewall guidance

Apply the same hardening as port 8080: remove /jmx-console, /web-console, /invoker/* servlets from deployments. Disable HTTP invoker in standalone.xml. Block management port (10090) from all but admin networks. Keep JBoss/WildFly patched – deserialization CVEs are frequently discovered. Use a reverse proxy with TLS for client-facing traffic.

Diagnosis commands

Test for CVE-2017-12149 (should return 404, not 500 – 500 means vulnerable)

shell
curl -s http://host:8180/invoker/readonly -o /dev/null -w '%{http_code}'

Check if JMX console is exposed (should be 404 or 403)

shell
curl -s http://host:8180/jmx-console/ -o /dev/null -w '%{http_code}'

Identify JBoss by default page title

shell
nmap -p 8180 --script http-title target

Test management console with common defaults (offset 100 from 9990)

shell
curl -s http://host:10090/management -u admin:admin

Usage examples

Port 8180 – JBoss / WildFly HTTP
shell
standalone.sh -Djboss.socket.binding.port-offset=100
curl http://localhost:8180/myapp/
/opt/wildfly/bin/jboss-cli.sh --connect controller=localhost:10090

Common services on this port

JBoss EAPWildFlyJBoss AS 4.x/5.x/6.x (legacy)Tomcat (also uses port offsets)

Related ports

8080

JBoss/WildFly primary HTTP

9990

WildFly management (primary)

10090

WildFly management (offset 100)

8109

AJP with offset 100 (8009+100)

History

JBoss Application Server was created by Marc Fleury in 1999 as the first free Java EE application server. Red Hat acquired JBoss in 2006. WildFly (the community name since 2013) introduced socket binding port offsets to run multiple instances on one host – common in development and legacy production environments where separate VMs per instance was cost-prohibitive. JBoss's history of RCE vulnerabilities (invoker servlets, deserialization, JMX console) makes any exposed instance high-risk.

FAQ

How do I check if my JBoss is vulnerable to deserialization attacks?

Run: curl -s http://host:8180/invoker/readonly. If it returns HTTP 500 (not 404), the endpoint exists and is likely vulnerable to CVE-2017-12149. Also check: /invoker/JMXInvokerServlet, /invoker/EJBInvokerServlet. Fix: remove invoker-service.xml from deploy/, or upgrade to WildFly 10+ which removed these servlets entirely. For immediate mitigation: block /invoker/* paths in your reverse proxy.

Should I still use JBoss port offsets in 2024+?

No. Use containers (Docker/Kubernetes) instead – each instance gets its own port namespace, proper isolation, and independent scaling. Port offsets were a workaround for bare-metal/VM deployments running multiple instances. They make monitoring confusing (port 10090 vs 9990), increase attack surface, and complicate firewall rules. Migrate to one-instance-per-container with standard ports.