Port 8008 – HTTP-Alt (Chromecast Control, Matrix Synapse, Alt-HTTP Web Services)

Port 8008 is one of the IANA-registered alternate HTTP (“http-alt”) ports, so a plain HTTP service can answer here just as it would on 80 or 8080. What makes 8008 worth a second look is what commonly listens on it. Two very distinctive real services default to this port: Google Cast / Chromecast devices expose their unauthenticated HTTP control API on 8008 (with a TLS companion on 8009), and Matrix Synapse homeservers bind their client and federation HTTP listener to 8008 behind a TLS reverse proxy. Beyond those, 8008 is a routine pick for internal web apps, proxies, and dev servers when the usual ports are taken. So the first job on an open 8008 isn’t to attack “HTTP” generically — it’s to identify whether you’re looking at a Chromecast/Cast device, a Matrix homeserver, or a generic web app, and then test that specific thing.

Why It’s Open

Port 8008 is open because something wanted an HTTP listener that wasn’t on 80. In practice it falls into three buckets:

• Google Cast / Chromecast device control. Chromecast dongles, Google/Nest smart displays, Android TV, and other Cast receivers run an HTTP control service on 8008 and a TLS-protected Cast v2 (protobuf) channel on 8009. The 8008 service speaks the DIAL (“Discovery and Launch”) protocol and a set of /setup endpoints, and it ships with no authentication — anything that can reach the port can query device info and launch or stop apps. This is a design decision, not a bug: Cast assumes it lives on a trusted LAN.
• Matrix Synapse homeserver. Synapse’s default homeserver.yaml exposes an unencrypted HTTP listener on 8008 carrying both the client-server API (/_matrix/client/...) and, in single-port setups, federation. The intended deployment binds 8008 to 127.0.0.1 and puts nginx, Caddy, Apache, or HAProxy in front of it to terminate TLS on 443/8448. An 8008 reachable directly from the internet usually means that reverse proxy was skipped or misconfigured.
• Generic alt-HTTP. Web proxies, containerized microservices, internal admin panels, and development servers routinely bind 8008 simply because 80/8080 were already in use. On a random cloud host this is the most likely occupant.

Common Risks

• Unauthenticated Chromecast/Cast control. If 8008 (and 8009) are exposed beyond the LAN — typically via a router that UPnP-forwarded them — anyone on the internet can read device details from /setup/eureka_info, force the device to launch a YouTube/media app, rename it, or reboot it, all without credentials. This is the flaw behind the mass “CastHack” hijacks.
• Synapse exposed without its reverse proxy. A Synapse HTTP listener facing the internet directly loses the TLS, rate-limiting, and header hardening the proxy was supposed to provide, and puts the full client/federation API — including media and state-resolution surfaces with real DoS CVEs — in front of untrusted callers.
• Cleartext HTTP. Traffic on 8008 is unencrypted by default (that’s the whole reason it sits behind a proxy). Anyone on the path can sniff sessions, tokens, or API calls.
• Generic web-app vulnerabilities. An alt-HTTP app on 8008 is exposed to the usual injection, XSS, CSRF, auth-bypass, and misconfiguration bugs of whatever framework is behind it.
• Open or misconfigured proxy. A proxy bound to 8008 without an allowlist can relay attacker traffic or reach internal resources, bypassing network controls.
• Information disclosure. Device names, SSIDs, software versions, and Server: headers on 8008 hand an attacker exactly the fingerprint they need to pick the right follow-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 8008 is identifying the service before you test it. Start with a version scan and headers, then branch on what answers.

Detect the service and version

nmap -sV -p 8008,8009 <target>
nmap -sV --script http-headers,http-title -p 8008 <target>

Scanning 8009 alongside 8008 is deliberate: an open 8009 next to 8008 is a strong signal you’re looking at a Cast device, since 8009 is the Cast TLS companion port.

Fingerprint with the Server header

curl -sI http://<target>:8008/

A generic Server: / X-Powered-By header points to a normal web app or proxy — test it like any other HTTP stack. No useful header, or one of the service-specific responses below, narrows it down fast.

Test for a Chromecast / Cast device (DIAL)

# Device info — returns JSON with name, SSID, build/version if it's a Cast device
curl -s http://<target>:8008/setup/eureka_info

# DIAL app state (unauthenticated by design)
curl -s http://<target>:8008/apps/YouTube

A JSON body naming the device confirms an unauthenticated Cast receiver. Purpose-built clients such as catt (Cast All The Things) and the pychromecast library drive these devices from the command line — useful for demonstrating, in a report, that app-launch and reboot are reachable without auth.

Test for a Matrix Synapse homeserver

# Synapse advertises its supported client-API versions here, unauthenticated
curl -s http://<target>:8008/_matrix/client/versions

A JSON list of r0/v1 versions confirms a Synapse (or Matrix-compatible) homeserver whose HTTP listener is reachable — note whether you reached it directly (a misconfiguration) or through a 443 proxy.

Log every open 8008/8009, the service you positively identified, and any unauthenticated control you confirm, 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 generic “port 8008” CVE — the risk depends entirely on which of the three occupants is answering.

• Chromecast / Google Cast is a design issue, not a CVE. The unauthenticated 8008/DIAL control surface behaves exactly as designed: Cast assumes a trusted home LAN and ships without authentication. The mass “CastHack” hijacks weren’t a software vulnerability but exposure — home routers UPnP-forwarding 8008/8009 to the public internet, where the by-design open API could be driven by anyone. There is no patch to apply; the fix is network exposure (see Mitigation). Don’t expect a CVE here.

• Matrix Synapse has real, network-reachable CVEs — but they belong to the Synapse product and version, not to port 8008, and only apply if the service on 8008 is actually a Synapse homeserver:

  • CVE-2024-37302 — Synapse (Element) before 1.106. An unauthenticated attacker abuses insufficient rate limiting to make Synapse download and cache large amounts of remote media, exhausting disk and causing denial of service. CVSS 7.5 (High). Reachable over the same HTTP surface that defaults to 8008.
  • CVE-2024-31208 — Synapse before 1.105.1. An authenticated remote Matrix user sends crafted events that exploit a flaw in the V2 state-resolution algorithm, driving excessive CPU use and database bloat (denial of service) across federated servers. CVSS 6.5 (Medium).

  If you confirm a Synapse instance, fingerprint its exact version and check that version against Synapse’s advisories rather than treating “port 8008” as the vulnerable thing.

• Generic web app on 8008: the CVEs to check are those of whatever framework/proxy is behind it, at its specific version — not of the port.

Removed as wrong-service / unverifiable: the previous version of this page listed CVE-2025-2468 (“proxy bypass”), CVE-2024-9753 (“auth bypass in dev server”), CVE-2023-8642 (“info disclosure via debug endpoints”), and CVE-2023-3579 (“RCE through proxy misconfiguration”). Verified against NVD, none of these describe a port-8008 service: CVE-2024-9753 is an out-of-bounds read in Tungsten Automation Power PDF, CVE-2023-3579 is a CSRF flaw in HadSky 7.11.8, and CVE-2025-2468 and CVE-2023-8642 are not published records in the NVD. They have been removed. Always confirm a CVE’s product and description on NVD before trusting it against a port.

Mitigation

• Identify the real service first. You can’t secure 8008 generically — fingerprint whether it’s a Cast device, a Synapse homeserver, or a web app, then harden that specific thing.
• For Chromecast / Cast devices: never expose 8008 or 8009 to the internet. Disable UPnP on the router so devices can’t punch these ports open automatically, keep Cast devices on a segmented IoT VLAN, and firewall 8008/8009 to the LAN only. There’s nothing to authenticate — the only control is reachability.
• For Matrix Synapse: bind the 8008 listener to 127.0.0.1 and put a reverse proxy (nginx/Caddy/Apache/HAProxy) in front of it to terminate TLS on 443/8448, set x_forwarded: true, keep Synapse patched (the media rate-limit and state-resolution DoS bugs above are fixed in current releases), and never publish 8008 directly.
• For generic web apps/proxies: don’t expose dev/internal services to untrusted networks — bind to localhost or sit behind an authenticated, TLS-terminating reverse proxy, disable open-proxy behavior with a strict allowlist, and turn off verbose/debug errors on anything internet-facing.
• Encrypt in transit. 8008 is cleartext by default; front it with TLS rather than serving sensitive traffic in the clear.
• Firewall and rescan. Restrict 8008 (and 8009 for Cast) to the hosts that legitimately need it, and confirm with nmap -p 8008,8009 <target> after the change.

Real-World Example

In January 2019, the “CastHack” campaign run by the researchers known as HackerGiraffe and j3ws3r hijacked thousands of Chromecasts, smart TVs, and Google Home devices worldwide. There was no exploit code and no CVE — the devices’ HTTP control API on port 8008 is unauthenticated by design, and consumer routers had UPnP-forwarded 8008/8009 straight to the public internet. Using the ordinary DIAL app-launch mechanism, the attackers made every exposed device play a YouTube video that warned owners their devices were publicly reachable (and, in classic fashion, promoted a subscribe-to-PewDiePie message). They could also rename devices and read details from /setup/eureka_info. It’s the definitive port-8008 lesson: the service was working exactly as intended, and the entire vulnerability was network exposure — 8008 reachable from somewhere it never should have been.

FAQ

What is port 8008 used for?

Port 8008 is an IANA-registered alternate HTTP (“http-alt”) port. Its most distinctive real uses are Google Cast / Chromecast device control (an unauthenticated HTTP/DIAL API, with a TLS companion on 8009) and Matrix Synapse homeservers, which bind their client/federation HTTP listener to 8008 behind a reverse proxy. It’s also a common pick for generic web apps, proxies, and dev servers. On an open 8008, the first step is identifying which of these is answering.

Why is port 8008 open on my device or network?

Most often because a Google Cast / Chromecast device is present — those listen on 8008 (and 8009) permanently on the LAN. It can also be a self-hosted Matrix Synapse server, or any web app/proxy that chose 8008 because 80/8080 were taken. If 8008 is reachable from outside your network, check your router for UPnP port-forwarding, because that exposure is exactly what CastHack abused.

Is port 8008 the same as 8080 or 8000?

No. They’re all alternate-HTTP ports, but 8080 is more associated with proxies and Apache Tomcat, and 8000 with development servers and APIs, while 8008 has the distinctive Chromecast/Cast and Matrix Synapse defaults. See port 8000 and port 8080 for those. The response, not the number, tells you what’s really running.

Is the Chromecast API on port 8008 a security vulnerability?

The unauthenticated control API is by design — Cast assumes a trusted home network. It becomes dangerous only when 8008/8009 are exposed beyond the LAN, typically by a router that UPnP-forwarded them to the internet. There’s no patch; the fix is to keep those ports off the public internet and disable UPnP.

How do I tell whether it’s a Chromecast or a Matrix server on 8008?

Fingerprint it. curl -s http://<host>:8008/setup/eureka_info returns device JSON on a Cast device (and an open 8009 confirms it), while curl -s http://<host>:8008/_matrix/client/versions returns a version list on a Synapse homeserver. A plain Server: header with normal HTML/JSON points to a generic web app instead.

How do I secure or close port 8008?

Identify the service, then act: firewall Cast devices’ 8008/8009 to the LAN and disable router UPnP; for Synapse, bind 8008 to localhost behind a TLS reverse proxy and keep it patched; for web apps, put them behind authentication and TLS or bind them to localhost. Then rescan with nmap -p 8008,8009 <host> to confirm the exposure is gone.

TL;DR

• Service: alternate HTTP — most distinctively Google Cast / Chromecast control (8008 HTTP, 8009 TLS), Matrix Synapse’s client/federation HTTP listener behind a reverse proxy, plus generic web apps, proxies, and dev servers
• Default port: 8008/TCP (Cast TLS companion on 8009; Synapse federation often on 8448/443)
• Biggest risk: an unauthenticated Chromecast/Cast API exposed to the internet (the CastHack hijacks) or a Synapse HTTP listener published without its reverse proxy — identify which service is answering before you test it
• Mitigation: fingerprint the real service; keep Cast 8008/8009 on the LAN and disable UPnP; bind Synapse to localhost behind a TLS proxy and patch it; put web apps behind auth/TLS; firewall 8008 to hosts that need it and rescan