Port 8009 – AJP (Apache JServ Protocol)

Port 8009 is the default port for AJP, the Apache JServ Protocol — the packet-oriented binary channel that a front-end web server uses to hand requests to a Java application container behind it. In the classic setup, Apache HTTP Server (via mod_jk or mod_proxy_ajp) or another reverse proxy terminates the public HTTP/HTTPS traffic and forwards each request over AJP to a Tomcat (or Jetty) back-end that does the actual work, then relays the response back. AJP is faster and lower-overhead than proxying plain HTTP, and — crucially — it was designed as a trusted, internal link between two cooperating servers that were never supposed to be on the public internet. That design assumption is exactly what makes an internet-facing port 8009 dangerous: the protocol grants the caller elevated trust, so anyone who can reach 8009 directly can talk to Tomcat as if they were the trusted front-end. The Ghostcat vulnerability turned that trust into arbitrary file read and, on many hosts, remote code execution.

Why It’s Open

Port 8009 is open because a Java application server is running an AJP connector to receive forwarded requests from a front-end web server:

• Apache Tomcat historically shipped with an AJP Connector enabled by default, listening on all configured IP addresses (0.0.0.0:8009) in the stock server.xml. Countless installs never touched that default, which is why so many Tomcat hosts have an exposed 8009 alongside their HTTP connector on 8080 (and its HTTPS sibling on 8443). Alternate or secondary Tomcat instances that move their HTTP listener to 8180 still expose an AJP connector on 8009 unless it’s been disabled.
• Apache httpd + mod_jk / mod_proxy_ajp front ends connect to 8009. A load balancer or reverse proxy tier speaks AJP to one or more Tomcat/Jetty workers behind it, so 8009 is the plumbing between the web tier and the app tier.
• Jetty and other Java containers support AJP for the same front-end/back-end split and expose the connector on 8009 when it’s enabled.
• Appliances and bundled products that embed Tomcat (management consoles, middleware, enterprise apps) inherit the default AJP connector and quietly expose 8009 unless the vendor disabled it.

The key point: AJP is an internal transport. It is meant to sit on a private link between the proxy and the app server, reachable only from the front end — never from the internet or an untrusted LAN.

Common Risks

• Elevated trust by design. AJP requests carry attributes the back-end treats as coming from a trusted proxy. An attacker who reaches 8009 directly inherits that trust and can set request attributes the front-end would normally never allow — the root cause of Ghostcat.
• Arbitrary file read (Ghostcat). A crafted AJP request makes Tomcat return any file under the web application root — including WEB-INF/web.xml, configuration, credentials, and source code that are supposed to be unreachable over HTTP.
• Escalation to remote code execution. If the application lets a user upload any file to the server (an image, a document, a temp file), Ghostcat can point Tomcat at that file and have it processed as a JSP, turning file read into full RCE.
• Request smuggling through the proxy. A flawed mod_proxy_ajp front end can be tricked into smuggling requests to the AJP back-end, bypassing front-end access controls (CVE-2022-26377).
• Exposed internal channel. 8009 reachable from anywhere but the front-end proxy is a misconfiguration in its own right — it exposes a protocol that assumes it is talking only to trusted peers.
• Information disclosure. AJP discovery scripts and file-read primitives leak framework, version, and configuration detail an attacker then uses to pick an exploit.

Want to save time on reporting?

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

Book a Demo

Enumeration & Testing

The job on 8009 is to confirm AJP is answering, identify the Tomcat/Jetty version behind it, and test for Ghostcat. Everything here targets the AJP connector directly.

Confirm the service and version

nmap -sV -p 8009 <target>

Enumerate the AJP connector with Nmap’s AJP NSE scripts

# All three are real scripts in Nmap's AJP family (author: Patrik Karlsson)
nmap -p 8009 --script ajp-methods,ajp-headers,ajp-request <target>

ajp-methods lists the HTTP methods the connector allows (flagging risky ones like PUT/DELETE), ajp-headers returns the back-end’s response headers, and ajp-request issues a request over AJP and shows the result — a quick way to prove the connector is live and talking.

Test for Ghostcat (CVE-2020-1938) with the public PoC

# ajpShooter — the widely-used Python Ghostcat PoC (reads a file via AJP)
python3 ajpShooter.py http://<target> 8009 /WEB-INF/web.xml read

A successful read of WEB-INF/web.xml — a file that is never served over normal HTTP — confirms the host is vulnerable.

Test for Ghostcat with Metasploit

msfconsole -q
use auxiliary/admin/http/tomcat_ghostcat
set RHOSTS <target>
set RPORT 8009
run

auxiliary/admin/http/tomcat_ghostcat (module name “Apache Tomcat AJP File Read”, CVE-2020-1938) connects to the AJP port and reads a target file to prove the flaw.

Record every open port 8009, the Tomcat/Jetty version, and any file you successfully read over AJP, 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 AJP connector on 8009 is home to one of the most consequential Tomcat vulnerabilities of the last decade. Every CVE below was verified against its NVD record and is scoped to the AJP protocol / port 8009.

• CVE-2020-1938 — Ghostcat. The headline flaw. Apache Tomcat’s AJP connector gave requests elevated trust, and because Tomcat shipped with that connector enabled by default on all interfaces, an attacker who could reach 8009 could set the javax.servlet.include.* request attributes to make Tomcat return arbitrary files from anywhere in the web application (config, source, WEB-INF/web.xml) and, where the app allows a file to be uploaded, have that file processed as a JSP — escalating file read to remote code execution. Affected: Tomcat 9.0.0.M1–9.0.0.30, 8.5.0–8.5.50, and 7.0.0–7.0.99 (older EOL 6.x shared the same default-enabled connector and never received a fix). CVSS 9.8 (Critical). Weaponized in Metasploit as auxiliary/admin/http/tomcat_ghostcat; public PoCs include Exploit-DB 48143 (the ajpShooter-style Python file-read/inclusion script) and Exploit-DB 49039 (the Metasploit implementation).
• CVE-2022-26377 — mod_proxy_ajp request smuggling. An “Inconsistent Interpretation of HTTP Requests” (HTTP Request Smuggling) flaw in mod_proxy_ajp of Apache HTTP Server lets an attacker smuggle requests through the front-end proxy to the AJP back-end it forwards to, potentially bypassing front-end access controls. Affects Apache HTTP Server 2.4.0 through 2.4.53. CVSS 7.5 (High). Fixed in httpd 2.4.54.

A note on scope and honesty. Ghostcat is frequently mislabeled as a “port 8080” or generic “Tomcat HTTP” bug. It is not — it is a flaw in the AJP connector on port 8009, and it does not exist on the HTTP connector. This page files it correctly. There is no generic “port 8009” CVE: the risk here is the AJP connector’s design trust plus specific, verified CVEs in Tomcat and mod_proxy_ajp. Always confirm a CVE’s product and its port/protocol against the NVD record before trusting it.

Mitigation

• Don’t expose 8009 to untrusted networks. AJP is an internal transport. Firewall TCP/8009 so it is reachable only from the front-end proxy hosts that legitimately speak AJP, and audit cloud security groups and container port mappings for an accidental 0.0.0.0:8009.
• Disable the AJP connector if you don’t use it. If your Tomcat is fronted over HTTP or serves directly, comment out or remove the <Connector port="8009" ... /> line in server.xml entirely. Post-Ghostcat Tomcat releases ship it disabled by default — match that on older installs.
• Patch Tomcat. Upgrade to a fixed build (Tomcat 9.0.31+, 8.5.51+, 7.0.100+, or later) that closes CVE-2020-1938; retire EOL 6.x, which will never be fixed.
• Require the AJP secret. On the fixed connectors, bind AJP to the loopback/internal interface (address="127.0.0.1") and set secret/requiredSecret so the connector only accepts requests from a proxy that presents the shared secret.
• Patch the front end. Update Apache HTTP Server to 2.4.54+ to close the mod_proxy_ajp request-smuggling flaw (CVE-2022-26377).
• Verify with a rescan. After locking it down, confirm 8009 is unreachable from outside the proxy tier (nmap -p 8009 <target>) and that Ghostcat PoCs no longer return WEB-INF/web.xml. Capture the before/after state and any file you managed to read in your pentest report so the finding and its remediation are documented together.

Real-World Example

Ghostcat (CVE-2020-1938), disclosed by Chaitin Tech in early 2020, is the defining port-8009 incident. Because Tomcat had shipped for years with the AJP connector enabled on all interfaces, internet-wide scans found hundreds of thousands of hosts with an exposed, vulnerable 8009. The attack needed no authentication and no memory-corruption exploit: a single crafted AJP request set the servlet include attributes so Tomcat would read a file the HTTP connector would never serve — typically WEB-INF/web.xml — spilling database credentials, internal URLs, and configuration. On any application that let a user drop a file somewhere on disk (an avatar upload, a document store, even a temp file), attackers chained the file-read primitive into JSP execution and a shell. Public PoCs (ajpShooter) and a Metasploit module appeared within days, and mass exploitation followed. The lesson is the port-8009 lesson in full: AJP is a trusted internal channel that should never have been reachable from the internet, and treating any exposed 8009 as high risk is the only safe default.

FAQ

What is port 8009 used for?

Port 8009 is the default port for AJP, the Apache JServ Protocol — a binary, packet-oriented channel a front-end web server (Apache httpd via mod_jk or mod_proxy_ajp, or another reverse proxy) uses to forward requests to a Java back-end such as Apache Tomcat or Jetty. It’s the internal plumbing between the web tier and the application tier, designed for speed and for a trusted connection between two cooperating servers.

Why is port 8009 open on my server?

Almost always because you’re running Tomcat (or a product that embeds it) with its AJP connector enabled. Tomcat historically shipped with <Connector port="8009" /> turned on and listening on all interfaces in the default server.xml, so many hosts expose 8009 without anyone deliberately choosing to. If nothing fronts your Tomcat over AJP, you can safely disable the connector.

Is port 8009 dangerous to expose?

Yes. AJP grants its caller elevated trust because it assumes it is talking only to a trusted front-end proxy. Anyone who reaches 8009 directly inherits that trust — which is exactly how Ghostcat (CVE-2020-1938) turned an exposed connector into arbitrary file read and, on many hosts, remote code execution. Treat any 8009 reachable from outside the proxy tier as high risk.

What is Ghostcat?

Ghostcat is CVE-2020-1938, a critical (CVSS 9.8) flaw in Tomcat’s AJP connector. A crafted AJP request sets servlet include attributes that make Tomcat return any file under the web app root (like WEB-INF/web.xml); if the app also allows file uploads, that file can be processed as a JSP, giving remote code execution. It affects Tomcat 7.0.0–7.0.99, 8.5.0–8.5.50, and 9.0.0.M1–9.0.0.30.

Is Ghostcat a port 8080 bug?

No — this is a common mislabeling. Ghostcat is a vulnerability in the AJP connector on port 8009, not the HTTP connector on 8080. It’s worth scanning 8009 alongside 8080 on any Tomcat host, but the flaw and its fix belong to AJP.

How do I secure or close port 8009?

If you don’t use AJP, remove the <Connector port="8009" /> line from server.xml. If you do, patch Tomcat to a fixed build, bind the connector to an internal interface, set the secret/requiredSecret, and firewall TCP/8009 so only your front-end proxy hosts can reach it. Then rescan to confirm it’s no longer exposed.

TL;DR

• Service: AJP — Apache JServ Protocol, the binary front-end-to-back-end connector for Tomcat/Jetty (Apache httpd mod_jk / mod_proxy_ajp)
• Default port: 8009/TCP (internal transport — never meant to face the internet)
• Biggest risk: Ghostcat (CVE-2020-1938, CVSS 9.8) — arbitrary file read via the AJP connector, escalating to RCE where file upload is possible; plus mod_proxy_ajp request smuggling (CVE-2022-26377)
• Mitigation: disable the AJP connector if unused, patch Tomcat and Apache httpd, bind to an internal interface with a required secret, and firewall 8009 to the proxy tier only