Ghostcat Apache Tomcat AJP file read/RCE (CVE-2020-1938)

A single unauthenticated request to a rarely-noticed TCP port can hand an attacker your application's source code, database credentials, and — under the right conditions — a full remote shell. That is the story of CVE-2020-1938, better known as Ghostcat, a critical file-read and remote code execution (RCE) vulnerability in the Apache JServ Protocol (AJP) connector shipped with every default installation of Apache Tomcat for years. Because AJP listens by default and because so many organizations forgot it was even running, Ghostcat became one of the most widely scanned-for and exploited Java application server vulnerabilities of the last several years — and it is still being found in the wild today. This post breaks down what Ghostcat is, who it affects, how attackers weaponize it, and the concrete steps security and platform teams should take to close it out for good.

What is Ghostcat (CVE-2020-1938)?

Ghostcat is a vulnerability in Tomcat's AJP connector, the binary protocol Tomcat uses to talk to front-end web servers such as Apache HTTP Server (via mod_jk or mod_proxy_ajp) and IIS. AJP was designed under the assumption that anything speaking to it is a trusted, internal component — not a hostile client on the open internet. The connector is enabled and listening on TCP port 8009 by default, even on installations that never intentionally use it.

The flaw allows an attacker who can reach port 8009 to send a crafted AJP request that manipulates request attributes such as javax.servlet.include.request_uri and javax.servlet.include.path_info. Tomcat's RequestDispatcher then treats the attacker-supplied value as an internal include target, allowing the attacker to:

• Read arbitrary files from anywhere under the webapp's document root — including WEB-INF/web.xml, application source, configuration files, and anything else deployed alongside the app, often exposing credentials, session secrets, and API keys.
• Achieve remote code execution in any deployment where the attacker can also write a file into the webapp directory — most commonly through an unrestricted file upload feature. The attacker uploads a JSP file (even disguised as an image or text file) and then uses the AJP file-inclusion trick to have Tomcat execute it as a script, yielding a full webshell.

No authentication is required for either primitive. The only precondition is network reachability to port 8009 and, for the RCE path, some independent way to place a file inside the application.

Affected Versions and Components

Ghostcat affects the AJP connector across the entire actively-used Tomcat version tree at the time of disclosure:

• Apache Tomcat 9.x before 9.0.31
• Apache Tomcat 8.5.x before 8.5.51
• Apache Tomcat 7.x before 7.0.100
• Apache Tomcat 6.x — end-of-life and unsupported, but confirmed vulnerable with no official patch available

Any product or appliance that bundles one of these Tomcat versions inherits the exposure, which is why Ghostcat findings have shown up for years in embedded management consoles, monitoring tools, CI/CD servers, and enterprise middleware that developers didn't realize was running Tomcat under the hood. The vulnerability lives in the AJP connector itself, not in application code, so it affects every webapp deployed on a vulnerable Tomcat instance — patching or mitigating requires action at the server/infrastructure layer, not the application layer.

CVSS, EPSS, and KEV Context

• CVSS v3.1 Base Score: 9.8 (Critical) — reflecting a network-exploitable, unauthenticated vulnerability with high impact to confidentiality, integrity, and availability (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H).
• EPSS: Ghostcat has consistently scored in the very high percentile bands of the Exploit Prediction Scoring System, reflecting sustained, real-world scanning and exploitation activity across the internet since disclosure. Because EPSS is recalculated continuously, defenders should pull the current score for CVE-2020-1938 from the EPSS API or FIRST.org rather than relying on a point-in-time figure — but historically it has ranked among the most actively probed CVEs of its cohort.
• CISA KEV: CVE-2020-1938 appears on CISA's Known Exploited Vulnerabilities catalog, meaning federal agencies under Binding Operational Directive 22-01 are required to remediate it, and it is formally confirmed to have been exploited in the wild — not just theoretically exploitable.

The combination of a critical CVSS score, high EPSS-observed exploitation, and KEV inclusion makes Ghostcat a textbook "patch this now" finding wherever it turns up in an asset inventory, regardless of how old the CVE is.

Timeline

• December 2019 — Security researchers at Chaitin Tech's Elytrium/CodeSafe team privately identify and report the AJP file-read/inclusion issue to the Apache Tomcat security team.
• January 2020 — The Apache Software Foundation ships patched releases (Tomcat 9.0.31, 8.5.51, and 7.0.100) that introduce a secretRequired / requiredSecret authentication mechanism for the AJP connector and harden the file-inclusion logic.
• February 20, 2020 — CVE-2020-1938 is publicly disclosed and named "Ghostcat" by Chaitin Tech, accompanied by technical write-ups explaining the file-read and RCE chains.
• Late February 2020 — Multiple public proof-of-concept exploit scripts appear on GitHub within days, and mass internet-wide scanning for open port 8009 begins almost immediately, with honeypots recording exploitation attempts within 48 hours of disclosure.
• 2020–present — Ghostcat remains a persistent finding in penetration tests, red team engagements, and internet-wide vulnerability sweeps, driven by long-lived, unpatched, and often forgotten Tomcat deployments (including those embedded inside third-party products). Its addition to the CISA KEV catalog reflects this sustained real-world exploitation years after disclosure.

Remediation Steps

Ghostcat is straightforward to remediate once identified — the challenge is almost always discovery, not the fix itself. Prioritize in this order:

1. Patch Tomcat. Upgrade to Tomcat 9.0.31+, 8.5.51+, or 7.0.100+ (or the current supported release in each line). If you're running Tomcat 6.x, treat this as an urgent end-of-life migration — no patch exists and the platform carries other unaddressed risk beyond Ghostcat.
2. Disable the AJP connector if you don't use it. Most standalone Tomcat deployments don't front with mod_jk or mod_proxy_ajp and don't need AJP at all. Comment out or remove the <Connector port="8009" protocol="AJP/1.3" .../> element in conf/server.xml and restart Tomcat.
3. If AJP is required, lock it down. Set the connector's address attribute to 127.0.0.1 (or an internal-only interface) so it's unreachable from untrusted networks, and configure secretRequired="true" with a strong secret value so the connector rejects any request that doesn't present the shared secret — this is the mechanism the official patch introduced.
4. Restrict network access at the perimeter. Firewall port 8009 from the internet and from any network segment that doesn't specifically need it, regardless of whether you've applied the software fix. Defense in depth matters here because AJP has a history of being re-exposed by misconfiguration.
5. Hunt for prior compromise. If an unpatched, internet-facing AJP connector was discovered, don't stop at patching — review webapp directories for unexpected .jsp files, check access logs for anomalous AJP traffic or file-read patterns targeting WEB-INF/web.xml, and rotate any credentials that may have been exposed through file disclosure.
6. Inventory embedded Tomcat instances. Because Ghostcat often hides inside vendor appliances and bundled middleware, extend the hunt beyond servers you provisioned directly — check network scanning results and software bills of materials (SBOMs) for any product shipping an affected Tomcat version.

How Safeguard Helps

Safeguard is built to catch exactly this class of "old CVE, still everywhere" risk before it becomes an incident. Our SBOM generation and ingestion pipeline fingerprints every Tomcat instance and bundled dependency across your fleet — including versions hiding inside third-party products — so Ghostcat-affected deployments surface automatically instead of waiting for the next pen test. Reachability analysis then tells you which of those instances actually expose the AJP connector on a reachable network path and whether an upload feature exists that could turn the file-read primitive into RCE, so your team can triage the handful of genuinely exploitable instances instead of chasing every match in the CVE database. Griffin AI, Safeguard's security reasoning engine, correlates the CVSS, EPSS, and KEV signals covered above with your specific exposure context to prioritize Ghostcat findings against everything else competing for engineering attention. Where a fix is available, Safeguard can open an auto-fix pull request that bumps the affected Tomcat version or applies the hardened AJP configuration directly, cutting the time from detection to remediation from weeks to hours.