CVE-2020-1938: Ghostcat
Is CVE-2020-1938 real, exploitable, or a false positive? Here's the community verdict.
signals
public sources
Confirmed exploited in the wild. Patch this first, regardless of the base score.
public exploits
links to sources — we don’t host codeA working exploit is publicly available from a maintained source. Treat this as higher urgency and verify your exposure.
baseline read
auto · not a community verdict
Real — exploited in the wild
CISA confirms active exploitation. Treat scanner hits as true positives unless your specific version or config is unaffected.
Based on CISA KEV
Confirm or dispute →CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
When using the Apache JServ Protocol (AJP), care must be taken when trusting incoming connections to Apache Tomcat. Tomcat treats AJP connections as having higher trust than, for example, a similar HTTP connection. If such connections are available to an attacker, they can be exploited in ways that may be surprising. In Apache Tomcat 9.0.0.M1 to 9.0.0.30, 8.5.0 to 8.5.50 and 7.0.0 to 7.0.99, Tomcat shipped with an AJP Connector enabled by default that listened on all configured IP addresses. It was expected (and recommended in the security guide) that this Connector would be disabled if not required. This vulnerability report identified a mechanism that allowed: - returning arbitrary files from anywhere in the web application - processing any file in the web application as a JSP Further, if the web application allowed file upload and stored those files within the web application (or the attacker was able to control the content of the web application by some other means) then this, along with the ability to process a file as a JSP, made remote code execution possible. It is important to note that mitigation is only required if an AJP port is accessible to untrusted users. Users wishing to take a defence-in-depth approach and block the vector that permits returning arbitrary files and execution as JSP may upgrade to Apache Tomcat 9.0.31, 8.5.51 or 7.0.100 or later. A number of changes were made to the default AJP Connector configuration in 9.0.31 to harden the default configuration. It is likely that users upgrading to 9.0.31, 8.5.51 or 7.0.100 or later will need to make small changes to their configurations.
References
Published
Embed this verdict
[](https://www.truepositive.app/cve/CVE-2020-1938)<a href="https://www.truepositive.app/cve/CVE-2020-1938"><img src="https://www.truepositive.app/cve/CVE-2020-1938/badge.svg" alt="TruePositive verdict for CVE-2020-1938"></a>Live badge that updates automatically as the community verdict changes.
Community ground truth
Be the first practitioner to weigh in
So far this is only TruePositive's editorial baseline from public sources. Add your real-world verdict below — it becomes the signal the next person triaging this relies on.
🥇 The first 50 practitioners to contribute earn a Founding Contributor badge.
In your experience, is this finding real and exploitable?
awaiting field verdictsCurated baseline: TruePositive's read from public sources is Real, needs specific conditions — a starting point, not a community verdict.
No account needed. Anonymous verdicts post as an unverified signal. Log in to make yours verified and earn reputation.
Field notes & remediation
Verdicts are the quick signal. Notes are the evidence and fixes behind them.
- 0
This is conditional, and it matters only if the Tomcat AJP connector on port 8009 is reachable. When it is, an attacker can read files inside the web application, including config files, and if they can also get a file uploaded somewhere, that can be turned into remote code execution. Most internet-facing Tomcats do not expose AJP, but internal ones sometimes do, so this is often an internal-network risk.
Who is affected: Tomcat 6, 7, 8, and 9 with the AJP connector enabled and reachable.
How to check: is port 8009 open and reachable from where an attacker could sit? If AJP is not exposed, the real risk is low.
Commonly flagged by: Nessus, Qualys, OpenVAS.
- 0
Upgrade Tomcat to a fixed version. If you do not use AJP, disable the connector completely. If you do use it, bind it to localhost only and set a secret (the requiredSecret attribute) so it is not open. Then confirm port 8009 is not reachable from untrusted networks.