Port 8082 – HTTP-Alt (Alternate Web & API-Proxy Port)

Port 8082 is not a registered service port — it is a generic alternate-HTTP port, one of the numbers software reaches for when 80, 443, and 8080 are already taken. In practice it clusters around one role more than any other: API gateways, REST/HTTP proxies, and secondary web dashboards. The single most common named occupant is the Confluent/Apache Kafka REST Proxy, which binds 8082 out of the box to expose Kafka over HTTP. You will also find monitoring and proxy dashboards, microservice API tiers, and the web UIs of IoT and embedded devices here. Because nothing is guaranteed to be on 8082, the first job on an open port isn’t to attack a known protocol — it’s to fingerprint what is actually answering, then test that specific thing.

Sibling alternate-HTTP ports — fingerprint the actual service. Ports 8099 and 8181 are the same kind of generic HTTP-alt port with no fixed service. Whatever guidance you read for one, the rule is identical across all three: identify the running product and version before you test it. Don’t assume the service from the port number.

Why It’s Open

Something is deliberately listening on 8082 because a standard web port was unavailable or reserved for a different tier. The recurring reasons:

• Kafka REST Proxy. The Confluent/Apache Kafka REST Proxy binds 8082 by default. It exposes a full HTTP/REST interface over a Kafka cluster — list brokers/topics/partitions, produce messages, run stateful consumers, and (via the v3 admin API) create or delete topics. Authentication is not enabled by default; Confluent ships a separate REST Proxy Security Plugin that operators are expected to install for production.
• API gateways and REST proxies. 8082 is a common pick for an API-gateway or reverse-proxy front end sitting in front of microservices, separate from the main 8080 web tier.
• Secondary admin/monitoring dashboards. Proxy managers, metrics/monitoring consoles, and internal tooling frequently land a second web UI on 8082 to keep it off the primary port.
• IoT and embedded device web UIs. Routers, NVRs, and embedded appliances sometimes serve their management interface on 8082.

On a server, an open 8082 usually means a message-bus proxy or an API/admin tier; on an appliance it’s often a device management UI. Either way it is an HTTP endpoint you fingerprint like any other.

Common Risks

• Unauthenticated Kafka REST Proxy. An internet- or LAN-exposed REST Proxy with no security plugin lets anyone read topic metadata, consume message contents, and produce arbitrary records — full data-plane access to the message bus over plain HTTP.
• Exposed API gateway / proxy. A gateway on 8082 may forward to internal services with weak or missing authentication, or be abused as an open forwarder to reach hosts behind it.
• Default and weak credentials. Secondary dashboards and device UIs on non-standard ports are frequently left on vendor defaults because “nobody knows they’re there.”
• Cleartext HTTP. Alt-HTTP ports are commonly plain HTTP, so credentials, tokens, and message payloads travel unencrypted.
• Information disclosure. Debug endpoints, verbose error pages, Server/X-Powered-By headers, and metrics endpoints leak framework, version, and internal topology.
• Standard web app flaws. Whatever framework answers here carries the usual injection, access-control, and deserialization risks — assess the identified stack, not the port.

Want to save time on reporting?

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

Book a Demo

Enumeration & Testing

The whole game on port 8082 is identifying the service before you test it. Start with version detection and the HTTP headers, then branch on what answers.

Detect the service and version

nmap -sV -p 8082 <target>

Read the HTTP headers and title

curl -sI http://<target>:8082/
nmap -p 8082 --script "http-headers,http-title,http-server-header" <target>

Inspect the Server and X-Powered-By headers and any body/favicon to fingerprint the framework (Jetty, nginx, Express, an embedded HTTP stack, etc.).

Fingerprint the web technology

whatweb http://<target>:8082/

Check whether it’s a Kafka REST Proxy

The REST Proxy answers metadata requests over HTTP. A JSON topic list confirms it — and if it answers without credentials, that’s an unauthenticated proxy:

# List topics (v2 API) — a JSON array of topic names identifies a Kafka REST Proxy
curl -s http://<target>:8082/topics \
  -H "Accept: application/vnd.kafka.v2+json"

# Cluster/broker metadata via the v3 admin API
curl -s http://<target>:8082/v3/clusters

If those return topic or cluster data with no auth, the message bus is exposed — note it as a high-severity finding rather than probing further into production data.

Enumerate paths on an unknown web app

ffuf -u http://<target>:8082/FUZZ -w /usr/share/seclists/Discovery/Web-Content/common.txt
nmap -p 8082 --script http-enum <target>

Capture every open port 8082, the service you positively identified, and any unauthenticated endpoint or credential that works, 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 CVE tied to “port 8082” itself — it is an unassigned alt-HTTP port, and any vulnerability belongs to whatever product happens to be listening. The security story here is a design/configuration one, not a memory-corruption bug:

• Unauthenticated Kafka REST Proxy (configuration risk, not a CVE). The Confluent/Apache Kafka REST Proxy binds 8082 by default and ships without authentication enabled. Left that way and reachable from an untrusted network, it grants read of topic metadata, consumption of message contents, and production of arbitrary records — effectively unauthenticated access to the message bus. The fix is operational: install the REST Proxy Security Plugin, require TLS/auth, and firewall the port. Always confirm the exact product and version you fingerprinted, then check that product’s advisories.

Removed as mislabeled. The previous version of this page listed three CVEs that are not port-8082 vulnerabilities and have been removed:

• CVE-2018-1000525 was cited as an “Nginx improper request handling” DoS. It is not nginx at all — NVD records it as a PHP object-injection flaw in OpenPSA. Wrong product entirely; removed.
• CVE-2019-0211 (NVD) is an Apache HTTP Server local privilege escalation (2.4.17–2.4.38) — it needs local code execution and has nothing to do with an exposed 8082 listener. Removed.
• CVE-2021-41773 (NVD) is a genuine path-traversal/RCE bug, but it is scoped to Apache HTTP Server 2.4.49 specifically — not to port 8082, which rarely runs stock Apache httpd. It only applies if you actually fingerprint Apache 2.4.49 here; presenting it as an “alternate HTTP port” risk was misleading, so it’s removed.

Verify every CVE against its NVD record and scope it to the exact product and version you identified on the port — never to the port number.

Mitigation

• Identify the real service first. You cannot secure port 8082 generically — fingerprint whether it’s a Kafka REST Proxy, an API gateway, a dashboard, or a device UI, then harden that specific thing.
• If it’s a Kafka REST Proxy: install the REST Proxy Security Plugin, require authentication and TLS, restrict which principals can produce/consume, and never expose 8082 to untrusted networks. Keep it on an internal segment reachable only by the services that need it.
• If it’s an API gateway or proxy: enforce authentication and authorization at the gateway, disable open forwarding, and validate that upstream services aren’t reachable directly.
• Put HTTP behind TLS. Terminate on HTTPS/443 or a reverse proxy with a valid certificate so nothing on 8082 travels in cleartext.
• Replace default credentials on any dashboard or device UI, and disable debug endpoints and verbose errors on anything internet-facing.
• Firewall TCP/8082 to the clients that actually need it, and audit cloud security groups and container mappings for an accidental 0.0.0.0:8082.
• Close it if nothing legitimately needs it, and rescan to confirm.

Real-World Example

The canonical port-8082 finding is an exposed Kafka REST Proxy. Teams stand up the Confluent/Apache REST Proxy to let non-Java or web clients talk to Kafka over plain HTTP, it binds 8082 by default, and — because authentication is off out of the box and the Security Plugin is a separate install — the endpoint frequently ends up reachable with no credentials. From there an attacker issues GET /topics to enumerate every topic, consumes messages to read whatever business data flows through the bus (orders, events, PII), and produces crafted records back into topics that downstream services trust. No exploit code and no CVE are involved: the whole compromise is an HTTP request to a default-configured proxy on a non-standard port nobody thought to firewall. It’s the port-8082 lesson in miniature — the port is mundane and unassigned, but the service that happens to answer on it is the real attack surface, and identifying it is the entire job.

FAQ

What is port 8082 used for?

Port 8082 is a generic alternate-HTTP port with no officially assigned service. It’s most associated with API gateways, REST/HTTP proxies, and secondary web dashboards — and its best-known named occupant is the Confluent/Apache Kafka REST Proxy, which binds 8082 by default. It also hosts monitoring consoles, microservice API tiers, and embedded-device web UIs. On any open 8082, identify the specific service before assessing it.

Why is port 8082 open on my server?

Because some application chose it when 80/443/8080 were taken. Commonly that’s a Kafka REST Proxy, an API gateway or reverse proxy, an internal admin/monitoring dashboard, or a device’s management interface. Fingerprint it with curl -sI http://<host>:8082/ and nmap -sV -p 8082 <host> to learn what’s actually running.

Is port 8082 dangerous to leave open?

The port itself is harmless; the risk is whatever is behind it. An unauthenticated Kafka REST Proxy, a debug/dev app, or an open API gateway on 8082 is worth locking down or closing. A properly authenticated service behind TLS, firewalled to the clients that need it, is generally fine. Don’t publish 8082 to untrusted networks without knowing exactly what answers there.

How do I check what’s running on port 8082?

Fingerprint it: nmap -sV -p 8082 <host>, read the headers with curl -sI http://<host>:8082/, and run whatweb http://<host>:8082/. A JSON reply to GET /topics (with Accept: application/vnd.kafka.v2+json) identifies a Kafka REST Proxy; a Server/X-Powered-By header points to a specific web framework; a login page points to a dashboard or device UI.

Does port 8082 have any CVEs?

No CVE is tied to port 8082 itself — it’s an unassigned port, so vulnerabilities belong to the specific product you fingerprint. The most important 8082 risk is a configuration one: a Kafka REST Proxy exposed without authentication. Older stub pages listing Apache/nginx CVEs “for alternate HTTP ports” were mislabeled; scope every CVE to the actual product and version, not the port number.

What’s the difference between ports 8082, 8099, and 8181?

None inherently — all three are generic alternate-HTTP ports with no fixed service. See port 8099 and port 8181. For every one of them the methodology is the same: fingerprint the running product and version, then test that, rather than assuming the service from the port.

TL;DR

• Service: no single standard — a generic alternate-HTTP port, most often an API gateway, REST/HTTP proxy, or secondary dashboard; the Confluent/Apache Kafka REST Proxy binds 8082 by default. Siblings: 8099, 8181; related web-alt ports 8080 and 8000.
• Default port: 8082/TCP (HTTP)
• Biggest risk: an unauthenticated Kafka REST Proxy (read/produce/consume the message bus over plain HTTP) or any exposed API/dashboard — a configuration flaw, not a port-specific CVE. Fingerprint what’s answering before you trust it.
• Mitigation: identify the real service, enable auth/TLS (install the REST Proxy Security Plugin for Kafka), replace default creds, and firewall 8082 to the clients that need it. Capture findings in the pentest report.