How do you patch or mitigate CVE-2020-1938 (Apache Tomcat Improper Privilege Management)?

CISA’s required action for CVE-2020-1938 is to apply updates per vendor instructions. In practice, find every instance of Apache Tomcat in your estate, apply the vendor security update or documented mitigation, and if no fix can be applied, remove internet exposure or take the product out of service. After patching, review logs for signs of earlier exploitation, because attackers used this flaw in the wild.

What to check before you patch Apache Tomcat

Start by inventorying every Tomcat deployment, including embedded or forgotten instances on application servers, test systems, and internet-facing hosts. For this kind of CVE, the practical question is not only “is it installed?” but “is it reachable, and can an attacker interact with the vulnerable path before you remediate?” That distinction determines whether you can wait for a maintenance window or need immediate containment.

Because this flaw was actively exploited, triage should be driven by exposure first, then by the patch plan. A vulnerable instance behind trusted network controls is still a finding, but a vulnerable public instance is the one that most often needs emergency action. For prioritisation, use the CISA Known Exploited Vulnerabilities Catalog alongside asset ownership data so you do not miss unmanaged Tomcat deployments.

A Tomcat deployment can also be “present” in more than one form, so verify whether the vulnerable version is packaged inside an application bundle, a container image, a VM template, or a platform image. If you patch only the base host and leave the bundled runtime untouched, you can believe the issue is closed while the exploitable component remains live.

How to remediate when the vendor fix is available

The cleanest path is to apply the vendor security update exactly as directed and then verify the running instance, not just the package repository. For Tomcat, that means confirming the deployed binaries or container layers were actually replaced, the service restarted cleanly, and the exposed endpoint now reports the remediated build or mitigation state.

In parallel, align the remediation with your broader patch process rather than treating it as a one-off exception. A disciplined patch workflow, with rollout rings, rollback planning, and evidence of completion, makes it easier to move quickly on exploited issues without losing control of change risk. NHIMG’s Patch Management Guide is useful when you need an operational model for emergency patching, verification, and reporting.

If the same patch is being applied across multiple Tomcat instances, prioritise externally reachable servers and systems that host sensitive applications first. That sequence reduces the chance that an exposed service remains available long enough for follow-on compromise while lower-risk internal systems are being scheduled.

What to do if you cannot patch immediately

If the fix cannot be applied right away, the best mitigation is to reduce or remove the attack surface rather than assume the service is “safe enough” because it is monitored. Take the instance out of internet exposure, place it behind stronger access controls, or remove the product from service until you can remediate. Mitigation should be treated as temporary containment, not as an equivalent substitute for the vendor fix.

Where operational constraints force delay, use the short window to reduce blast radius. Restrict who can reach the service, limit adjacent administrative access, and make sure the instance is not carrying unnecessary privileges or embedded secrets that would widen the impact of compromise. NHIMG’s Privileged Access Management Guide is a good companion when the mitigation problem includes access boundaries as well as patch timing.

If you must keep a vulnerable system online, document the exception, set a clear expiration date, and attach a monitoring requirement to it. Exceptions that do not have a deadline tend to become permanent exposure.

Risk and Threat Considerations

This CVE matters because it was used in the wild, which means unpatched systems are not just theoretically vulnerable. The main risk is that an attacker can move from a reachable Tomcat instance into application compromise, persistence, or lateral movement before defenders notice the service is exposed.

Failure mechanism: An attacker targets an internet-facing or otherwise reachable Tomcat deployment, exploits the privilege-management weakness, and uses that foothold to interact with the host or hosted application in ways that should not have been possible.

Impact: The result can be unauthorized access, service abuse, planting of webshells or other persistence, and the need to assume the server may already have been used for earlier compromise even after the patch is applied.

Standards & Framework Alignment

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

MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST CSF 2.0, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Tomcat remediation depends on identifying, prioritizing, and fixing exposed vulnerable software.
Recommendation — Prioritize exposed Tomcat systems and verify remediation outcomes in your vulnerability management workflow.
NIST CSF 2.0	PR.IP-12 — Vulnerability management	The question is about patching and mitigations for a known exploited vulnerability.
Recommendation — Track vulnerable Tomcat instances through remediation, validation, and exception handling.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	This CVE response is centered on applying vendor updates and mitigating unpatched systems.
Recommendation — Apply vendor fixes promptly and document compensating mitigations until the flaw is closed.
OWASP ASVS	V15 — Secure Coding and Architecture	Tomcat exposure and remediation affect application deployment hardening and runtime architecture.
Recommendation — Harden deployment paths so vulnerable application runtimes are not left exposed in production.
MITRE ATT&CK	T1190 — Exploit Public-Facing Application	The flaw was exploited in the wild through a publicly reachable service.
Recommendation — Hunt for exploitation of externally reachable Tomcat services and investigate post-compromise activity.

Practitioner Guidance

What to verify: Confirm that every Tomcat instance is accounted for, that the vulnerable component has actually been updated or contained, and that the deployed state matches the intended remediation, not just the change ticket.

What to prioritise: Publicly reachable systems, shared application platforms, and Tomcat instances that support sensitive workflows should be handled before low-exposure internal servers, because those are the most likely to be hit first.

What to measure: Track how quickly exposed instances are either patched or removed from exposure, and keep evidence of post-remediation validation and log review so you can prove the issue was closed rather than merely scheduled.

Practitioner takeaway: For an exploited Tomcat CVE, speed matters, but exposure control and post-patch verification matter just as much. Patch first when you can, contain immediately when you cannot, and always assume you may need to investigate for prior compromise after the fix is in place.