Port 8080 and 8443 Exposure Guide: Find, assess and close alternate HTTP services

Ports 8080 and 8443 are where web services that were never meant to face the internet end up facing it: admin consoles, build servers, application servers, appliance management pages and developer test instances. Because they sit off the standard 80 and 443, they often bypass the web application firewall, the reverse proxy, the certificate inventory and the review process that the main website goes through. This guide explains what normally listens on these ports, why exposure is risky, how to find every instance from the outside and the inside, and how to decide between closing, restricting and fronting each one. It is for network, infrastructure and application security teams who own perimeter exposure, and for anyone who has just seen 8080 or 8443 in a scan report and needs to know what to do.

Key takeaways

• The port number tells you little about the service. IANA registers 8080 as http-alt ("HTTP Alternate") and 8443 as pcsync-https, but in practice both carry any HTTP or HTTPS application whose default or example configuration happened to use them.
• Management interfaces are the main risk. Application server managers, CI servers and network appliance web consoles commonly listen on these ports, and CISA's BOD 23-02 requires US federal agencies to take internet-exposed management interfaces off the internet or behind a separate zero trust enforcement point within 14 days.
• Defaults bind to every interface. Jenkins listens on 8080 on 0.0.0.0 by default, and Docker's -p 8080:80 publishes on every host address and, with ufw, routes traffic before ufw's rules apply.
• Close, restrict or front, in that order. Remove what nobody needs, limit what administrators need to a management network or zero trust access, and put anything that must be public behind the same proxy, WAF and TLS controls as the main site.
• Measure from outside, continuously. A one-off scan finds today's exposures; the new ones appear when someone starts a container or a vendor enables remote support.

What usually listens on 8080 and 8443

Both ports became conventions because they sit above 1024, so a non-root process can bind them on Unix-like systems, and they are easy to remember as "80 plus" and "443 plus". Product documentation then reinforced the habit. Apache Tomcat ships a non-TLS HTTP/1.1 connector on 8080 by default, and its SSL documentation uses 8443 as the example TLS connector port, telling readers to change the non-TLS connector's redirectPort if they choose another. Jenkins listens on 8080 by default.

Why exposure on these ports is worse than it looks

• They skip the front door: WAF, CDN and reverse proxy rules are usually written for 80 and 443. A service on 8443 on the same public IP is reached directly, without rate limiting, bot filtering or virtual patching.
• They are under-inventoried: certificate management, vulnerability scanning profiles and change control often only cover named websites. A service on an alternate port may run an out-of-date version for years.
• They hold privileged functions: deploying a WAR file through the Tomcat Manager or running a pipeline in a CI server is code execution by design. A stolen or default password is enough.
• They are exploited at scale: CISA's Known Exploited Vulnerabilities catalog includes Apache Tomcat (for example CVE-2025-24813, added 1 April 2025), the Jenkins command line interface (CVE-2024-23897, added 19 August 2024) and the Cisco IOS XE Web UI (CVE-2023-20198, added 16 October 2023). Where products like these listen on alternate HTTP ports, exposure and patch status must be tracked together.
• They leak secrets: the Tesla Kubernetes cryptojacking incident began with a Kubernetes console that was open to the internet and exposed cloud credentials, the pattern that makes forgotten dashboards so costly.

Finding every instance

Use both an outside-in and an inside-out view, because each misses things the other catches.

1. External attack surface scan. Scan every public IP and cloud egress address you own for open TCP ports, not just 8080 and 8443. Include neighbours such as 8000, 8008, 8081, 8888 and 9443, which serve the same role. Record the HTTP title, server banner, TLS certificate subject and redirect target for each. See the Attack Surface Management Guide.
2. Cloud configuration review. List security groups, network security groups and firewall rules that allow 8080, 8443 or broad port ranges from 0.0.0.0/0 or ::/0, and load balancer listeners on those ports. Cloud rules change faster than on-premises firewalls.
3. Host and container inventory. On servers, list listening sockets and the owning process. In container hosts, list published ports and their host IP: a mapping shown as 0.0.0.0:8080 is reachable from every interface. Docker's documentation states that publishing container ports is insecure by default.
4. Firewall rule review. Search perimeter policies for objects named "http-alt", "8080", "8443" or "web-alt" and any "any service" rules to DMZ hosts.
5. Identify the product. For each finding, decide what it is (manager console, appliance UI, application, dev server) and who owns it. Unknown ownership is itself a finding.

Choosing between close, restrict and front

BOD 23-02 offers a useful yardstick even outside US federal agencies. For in-scope management interfaces (routers, switches, firewalls, VPN concentrators, proxies, load balancers and out-of-band server management such as iLO and iDRAC, managed over HTTP, HTTPS, SSH and similar protocols), agencies must either make the interface reachable only from an internal enterprise network, with an isolated management network recommended, or put it behind a zero trust policy enforcement point separate from the interface, which CISA prefers. Smaller organisations without a ZTNA product can meet the same intent with a VPN that requires MFA plus a firewall rule that only admits the VPN pool to management addresses. Larger organisations should aim for a dedicated management network and an access broker with per-session logging.

Hardening what stays reachable

• Bind narrowly: Jenkins supports --httpListenAddress=127.0.0.1 and --httpPort=-1 to disable plain HTTP when HTTPS is configured; Docker accepts -p 127.0.0.1:8080:80 so only the host can reach the container. Put a reverse proxy in front for remote users.
• Do not rely on host firewalls alone with Docker: Docker's documentation explains that traffic to published container ports is diverted in the nat table before it reaches the chains ufw uses, effectively ignoring ufw rules. Control exposure with the publish address, cloud security groups or perimeter firewalls.
• Lock down application server management: for Tomcat, keep the Manager and Host Manager undeployed unless needed; if needed, keep LockOutRealm, use strong passwords and configure RemoteCIDRValve (which limits access to localhost by default) to admin addresses only. Remove the examples application and normally remove ROOT and documentation from public instances. Set the Server port to -1 to disable the shutdown port. See the Apache Tomcat Hardening Guide.
• Remove plain HTTP: a service on 8080 is usually unencrypted. Tomcat's guidance notes that BASIC and FORM authentication send credentials in clear text. Redirect to TLS or disable the plain connector.
• Reduce fingerprinting: keep Tomcat's xpoweredBy off (the default) and set showServerInfo="false" on error reporting, so scanners cannot read the exact version.
• Front with the proxy: see the Proxies and Forward vs Reverse Proxy Security Guide for reverse proxy patterns that keep backends off the internet.

How to implement: a phased rollout

1. Week 1, discover: external scan, cloud rule export and host listener inventory; build one list with owner, product and decision.
2. Week 2, close the obvious: shut down dev, test and unowned services after a short owner notice. Record every closure so it can be reversed.
3. Weeks 2 to 4, restrict management: move appliance and server consoles to management access. Test admin access through the new path before removing the public rule, and keep the old rule disabled (not deleted) for one change window as the rollback.
4. Weeks 4 to 8, front public applications: publish through the reverse proxy on 443, run WAF rules in detection mode first, then block. Rebind backends to internal addresses.
5. Ongoing, prevent recurrence: policy-as-code checks that reject security group rules opening 8080 or 8443 to the internet without an exception tag, container platform rules that block host port publishing on public nodes, and continuous external scanning.

The week numbers are NHI Mgmt Group recommendations for a mid-sized estate; adjust to your change calendar.

Where identity fits

Most of the damage from an exposed 8080 or 8443 service comes from the credentials behind it: default or shared admin passwords on consoles, Tomcat manager users in tomcat-users.xml, Jenkins credentials and API tokens, and cloud keys sitting on the host. When you restrict a console, also rotate its admin credentials, remove shared accounts, put administrator sign-in behind MFA or SSO where the product allows, and treat any secret the service could read as potentially exposed for as long as it was public. See the Exposed .git Directory Response for a comparable credential-first response.

Detection and measurement

What to monitor:

• New listeners: external scan diffs showing a new open 8080, 8443 or neighbouring port on any owned address.
• Rule changes: cloud audit events creating or modifying security group or firewall rules for these ports from any source.
• Admin path access: web access logs for requests to /manager/, /host-manager/, Jenkins /script or /cli and appliance login pages from outside management ranges. See the Web Server Access Log Detection Guide.
• Unexpected protocol use: outbound connections to external hosts on 8080 or 8443 from servers that should not browse, which may indicate command and control on a non-standard port. See the MITRE ATT&CK T1571 Non-Standard Port.

Metrics that show it is working:

• Count of internet-reachable services on 8080, 8443 and neighbouring ports, by owner, trending to an agreed exception list.
• Percentage of exposed management interfaces behind a management network or separate enforcement point (target 100%).
• Mean time from a new external exposure appearing to closure or approved exception.
• Percentage of alternate-port services with an identified owner and product version.
• Number of KEV-listed products reachable on any alternate port (target zero).

Framework mapping

Common failure patterns

• Trusting the port label. Treating 8443 as "secure because it is HTTPS" while it serves an unpatched admin console.
• WAF on 443 only. The same application reached directly on 8080 at the same IP, bypassing every rule.
• Containers published on all interfaces. A quick docker run -p 8080 on a cloud VM, with ufw assumed to protect it.
• Vendor remote support left on. An appliance management UI opened to the internet for a support call and never closed.
• Closing the port but not rotating secrets. A dashboard that was public for months may already have leaked the credentials it could read, as the Tesla Kubernetes cryptojacking case showed.
• Scanning only 80 and 443. External scanning profiles limited to standard ports miss the whole category.

Practitioner checklist

• Scan all owned public addresses for 8080, 8443 and neighbouring alternate HTTP ports, and repeat continuously.
• Export cloud and perimeter rules that allow these ports from the internet and assign each an owner.
• Close dev, test and unowned services first, recording each closure for rollback.
• Move every management interface behind a management network or separate zero trust enforcement point with MFA.
• Publish required applications only through the reverse proxy and WAF on 443, with backends bound internally.
• Bind Jenkins, containers and local tools to 127.0.0.1 unless remote access is designed in.
• Undeploy or restrict Tomcat Manager with RemoteCIDRValve and LockOutRealm; disable the shutdown port.
• Rotate admin credentials and secrets on any service that was exposed.
• Track KEV entries for every product found on alternate ports and patch within your KEV deadline.
• Add policy-as-code checks to block new internet rules on these ports without an approved exception.

Standards and references

• CISA: Binding Operational Directive 23-02, Mitigating the Risk from Internet-Exposed Management Interfaces
• IANA: Service Name and Transport Protocol Port Number Registry
• Apache Tomcat: Security Considerations
• Apache Tomcat: SSL/TLS Configuration How-To
• Jenkins: Initial Settings
• Docker Docs: Port publishing and mapping
• Docker Docs: Packet filtering and firewalls
• CISA: Known Exploited Vulnerabilities Catalog

Related NHI Mgmt Group resources: Network Ports and Protocols Security Guide · Attack Surface Management Guide · Apache Tomcat Hardening Guide · Exposed RDP Compromise