Is CVE-2020-1938 (Apache Tomcat Improper Privilege Management) being exploited in the wild?

Yes. CISA added CVE-2020-1938 to its Known Exploited Vulnerabilities catalogue on 3 March 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Apache Tomcat treats Apache JServ Protocol (AJP) connections as having higher trust than, for example, a similar HTTP connection. Any organisation running the affected product should treat remediation as urgent.

What “being exploited in the wild” means for this Tomcat CVE

For this CVE, the practical question is not whether the flaw exists, but whether real attackers are already using it against exposed systems. CISA’s KEV listing is the strongest public signal that exploitation has moved beyond theory, which means the issue should be handled as an active exposure rather than a routine vulnerability-management item.

That distinction matters operationally because KEV-listed issues usually justify accelerated triage, short remediation windows, and a faster decision on compensating controls if patching is delayed. If you still have Apache Tomcat instances that expose the relevant AJP path, treat them as priority assets until you can confirm they are no longer reachable or vulnerable.

For broader triage discipline, use Zero-Day and Exploited Vulnerabilities Guide to align KEV status, exploitability, and emergency response into one workflow.

Why AJP trust boundaries make this flaw operationally sensitive

Apache Tomcat’s AJP handling assumes a higher-trust relationship than a normal HTTP connection, so the weakness is not just “a bad setting.” It is a trust-boundary problem: if an attacker can reach the AJP interface, they may be able to abuse that trust to obtain unintended privilege or influence request handling in ways operators did not expect.

That is why this class of issue is often more dangerous than a simple web bug. The exposed service path can sit outside the main application review process, and teams sometimes overlook it when they focus only on public web traffic. The result is a hidden attack surface that remains reachable long after the primary application is thought to be hardened.

Apache’s own documentation and the vendor advisory should be your version and configuration reference, while the CISA KEV record tells you why this CVE deserves urgent handling. For vulnerability triage, the CISA Known Exploited Vulnerabilities Catalog is the authoritative operational source.

What to do if patching or reconfiguration is delayed

If you cannot remediate immediately, focus on exposure reduction first: confirm whether AJP is enabled, whether it is reachable from untrusted networks, and whether any reverse proxy or network control can restrict access while you work the fix. For exploited vulnerabilities, shrinking reachability is often the fastest meaningful risk reduction you can achieve.

Also check whether the system has been externally scanned or probed, because a flaw that is actively exploited often leaves weak but actionable traces before full compromise is obvious. Review web and application logs, proxy logs, and host telemetry for unusual requests, unexpected backend activity, or configuration changes that indicate the interface was being exercised by someone other than normal application traffic.

For prioritisation support, pair your internal assessment with NIST National Vulnerability Database and the vendor advisory so you can confirm the affected exposure path without relying on secondary commentary.

Risk and Threat Considerations

When a vulnerability is both publicly disclosed and actively exploited, the main risk is not abstract technical weakness, it is time. Attackers can move quickly from proof-of-concept to mass scanning, and systems that still expose the affected interface become easy targets for opportunistic intrusion, follow-on privilege abuse, or laterally staged compromise.

Failure mechanism: An exposed AJP endpoint is trusted more than ordinary web traffic, so an attacker who reaches it can abuse that trust boundary before defenders notice that the service path itself is the problem.

Impact: The likely consequence is unauthorized access or unintended request handling on a Tomcat host, followed by compromise assessment, emergency containment, and possible credential or session review if the server handled sensitive application traffic.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	ID.RA-01 — Asset vulnerabilities are identified and documented	Active exploitation requires identifying exposed Tomcat assets and their vulnerability state.
	PR.DS-01 — Data-at-rest is protected	If Tomcat handles sensitive data, compromise can expose stored application data.
Recommendation — Inventory exposed Tomcat instances and document their vulnerability exposure before scheduling remediation. Protect stored application data on Tomcat hosts with encryption and access restrictions.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	This CVE demands urgent remediation because exploitation is already occurring in the wild.
	AC-4 — Information Flow Enforcement	Restricting AJP reachability directly reduces the attack path for this trust-boundary flaw.
Recommendation — Accelerate flaw remediation for exposed Tomcat systems and verify the fix was applied. Enforce network and flow restrictions so only intended systems can reach the AJP interface.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	KEV-listed exploitation requires rapid identification, prioritisation and remediation of vulnerable hosts.
Recommendation — Prioritise KEV-listed Tomcat instances for immediate remediation and verification.
OWASP ASVS	V12 — Secure Communication	The issue hinges on unsafe trust in a backend protocol path and its exposure controls.
Recommendation — Require secure backend communication paths and restrict direct exposure of privileged service channels.

Practitioner Guidance

What to verify: Confirm whether AJP is enabled, whether the interface is reachable from outside the intended trust zone, and whether any compensating network rule actually prevents untrusted access. If you cannot answer those three questions quickly, treat the host as still exposed.

Decision rule: If the service is internet-reachable or otherwise accessible from a low-trust segment, prioritise remediation ahead of routine backlog work. If patching is delayed, reduce exposure first and then perform compromise hunting before you declare the system clean.

Practitioner takeaway: KEV inclusion changes the question from “should we patch?” to “how fast can we remove exposure and prove we were not already hit?”