Apache Tomcat AJP vulnerability (CVE-2020-1938 'Ghostcat') patched

The Apache Tomcat project released security updates on 24 February 2020 to address CVE-2020-1938, dubbed "Ghostcat" by its discoverers at Chaitin Tech. This vulnerability in the Apache JServ Protocol (AJP) connector enables unauthenticated attackers to read arbitrary files from vulnerable servers and, under specific configurations, achieve remote code execution. Fixed versions include Tomcat 9.0.31, 8.5.51, and 7.0.100.

Understanding the Ghostcat Vulnerability

The AJP connector enables communication between Apache HTTP Server and Tomcat, allowing Apache to forward dynamic requests to Tomcat while serving static content directly. This architecture improves performance and enables features like SSL termination at the Apache layer.

The vulnerability exploits AJP's trust model. AJP assumes connections come from a trusted proxy server, not arbitrary internet clients. When AJP listens on network-accessible interfaces—as occurs in default Tomcat configurations—attackers can send crafted AJP requests directly, bypassing intended access controls.

File read capability: By manipulating AJP request attributes, attackers can trick Tomcat into serving files from outside the web application directory. This enables reading sensitive configuration files, database credentials, and application source code. The WEB-INF/web.xml file is commonly targeted as it often contains connection strings and API keys.

Remote code execution path: When Tomcat is configured to allow file uploads (even to restricted directories), attackers can upload JSP files and then use the file read vulnerability to execute them. This attack chain requires specific misconfigurations but was observed in real-world exploitation shortly after disclosure.

Attack Surface Assessment

Ghostcat affects any Tomcat installation where the AJP connector is enabled and network-accessible. The default configuration binds AJP to 0.0.0.0:8009, accepting connections from any interface. Internet-facing servers, cloud instances without security groups restricting port 8009, and internal servers accessible to compromised endpoints are all vulnerable.

Shodan and Censys scans revealed millions of internet-accessible AJP ports within hours of disclosure. Security researchers observed widespread automated exploitation attempts targeting sensitive files within the first week. Organizations with internet-exposed Tomcat servers faced immediate risk.

Internal network exposure creates lateral movement opportunities. An attacker who compromises any system on a network containing vulnerable Tomcat instances can pivot to read credentials and configuration data, potentially escalating from low-value initial access to critical database servers or internal applications.

Immediate Mitigation Steps

Organizations unable to immediately deploy patched Tomcat versions should implement compensating controls to reduce exposure.

Disable the AJP connector if not required. Many deployments enable AJP by default but only serve traffic through the HTTP connector. Comment out or remove the AJP connector definition in server.xml and restart Tomcat.

Bind AJP to localhost if the connector is required for local Apache integration. Change the connector configuration to address="127.0.0.1", preventing remote connections while maintaining proxy functionality.

Configure AJP secrets in Tomcat 8.5.51+ and 9.0.31+. The patched versions introduce secretRequired and secret attributes that require connecting clients to provide a shared secret. This prevents exploitation even if AJP remains network-accessible.

Implement firewall rules blocking port 8009 from untrusted networks. Network-level controls provide defense-in-depth even after patching, protecting against potential future AJP vulnerabilities.

Patching Procedure

For standalone Tomcat installations: Download the appropriate patched version from the Apache Tomcat download page. Back up existing installation directories, deploy the new binaries, and migrate customized configuration files. Test application functionality before directing production traffic to updated servers.

For container deployments: Update Docker image base layers to include patched Tomcat versions. Images from the official tomcat Docker Hub repository were updated within 24 hours of release. Rebuild application images with updated bases and redeploy.

For embedded Tomcat in frameworks: Spring Boot applications and similar frameworks embedding Tomcat may require dependency updates rather than direct Tomcat patching. Check framework security advisories for guidance on incorporating patched Tomcat versions.

Detection and Forensics

Your security team should investigate whether Ghostcat exploitation occurred before patching. AJP requests leave minimal logging by default, but several indicators suggest compromise attempts.

Network traffic analysis: AJP traffic on port 8009 from non-proxy sources shows potential exploitation. Review firewall logs and network flow data for connections to port 8009 from unexpected source addresses.

File access anomalies: Tomcat access logs may show requests for unusual paths like /WEB-INF/web.xml or /./ traversal patterns. While these could show web-based attacks rather than AJP exploitation, they warrant investigation.

New JSP files: If RCE occurred, attackers likely uploaded JSP webshells. Search web application directories for recently created or modified JSP files. Compare file listings against deployment baselines to identify suspicious additions.

Long-Term Security Improvements

Ghostcat highlights broader architectural concerns for Java application servers. Default-insecure configurations have been a recurring source of Tomcat vulnerabilities. If you are affected, review Tomcat hardening guides from CIS or OWASP and implement restrictive configurations as baseline rather than defaults.

Network segmentation between web tiers and application tiers would have prevented much Ghostcat exploitation. Restricting AJP access to designated proxy servers through network policy—not just configuration—provides defense-in-depth against connector vulnerabilities.

Vulnerability scanning for AJP exposure should be incorporated into continuous security monitoring. Many vulnerability scanners now include Ghostcat-specific checks that identify both vulnerable versions and exposed AJP connectors.

Container and Cloud Considerations

Modern Tomcat deployments often run in containers or cloud environments with unique security considerations.

Kubernetes deployments: Tomcat pods in Kubernetes should use network policies restricting ingress to the AJP port. Default pod networking often allows cluster-wide communication, enabling lateral movement if one pod is compromised.

Cloud load balancers: Verify that cloud load balancer security groups do not inadvertently expose port 8009. Health check configurations may open ports that should remain restricted.

Container image updates: Rebuild application containers with patched Tomcat base images. Audit image registries for containers still using vulnerable base layers and focus on rebuilds.

Response Checklist

1. Inventory Tomcat installations: Identify all Tomcat instances across development, staging, and production environments
2. Check version and exposure: Verify whether AJP connector is enabled and network-accessible for each instance
3. Apply immediate mitigations: Disable AJP, bind to localhost, or implement firewall rules while planning patches
4. Schedule patching: Plan coordinated updates across Tomcat fleets with appropriate testing
5. Investigate for compromise: Review logs and file systems for indicators of exploitation before patching
6. Update container images: Rebuild containerized applications with patched Tomcat base layers

AJP Protocol Vulnerability

CVE-2020-1938 (Ghostcat) exploited Apache JServ Protocol implementation enabling arbitrary file read and potential remote code execution. Default AJP connector configurations on port 8009 exposed vulnerable attack surface. Organizations required immediate assessment of Tomcat deployments and network exposure.

Exploitation Risk

Attackers could read sensitive configuration files including database credentials and application secrets. Combined with file upload functionality, remote code execution became achievable. Internet-facing AJP connectors faced highest risk requiring priority remediation.

Mitigation Approaches

Upgrading to patched Tomcat versions addresses the vulnerability directly. Disabling unused AJP connectors eliminates attack surface where protocol is unnecessary. Network segmentation restricts AJP access to trusted application server peers.

See also

Selected articles on related subjects.

Infrastructure · Credibility 91/100 · February 20, 2020

Microsoft Defender ATP for Linux enters public preview

Microsoft Defender ATP is coming to Linux. The preview dropped on February 20, 2020, supporting RHEL, CentOS, Ubuntu, Debian, SLES, and Oracle Linux. If you are already in the Microsoft security stack, you can now extend…

Infrastructure · Credibility 91/100 · February 19, 2020

Infrastructure — VMware Workstation

VMware patched privilege escalation bugs in Workstation, Fusion, and ESXi in February 2020. VMSA-2020-0005 covers several vulnerabilities. Update your hypervisors and endpoints.

Infrastructure · Credibility 73/100 · February 18, 2020

CISA alert on ransomware disrupting natural gas compression

A U.S. natural gas compression facility got hit with ransomware and had to shut down for two days. CISA's alert makes clear that OT networks are not immune—the malware spread from IT to operations. If you are running…

Infrastructure · Credibility 73/100 · March 2, 2020

Android March 2020 security bulletin ships critical fixes

Google's March 2020 Android security bulletin patches critical RCE bugs in the media framework. If you are running enterprise Android fleets, push these updates—attackers can exploit these through malicious media files.

Infrastructure · Credibility 91/100 · March 3, 2020

Let’s Encrypt mass certificate revocation for CAA bug

Let’s Encrypt disclosed a Certificate Authority Authorization (CAA) rechecking bug that violated issuance rules for roughly three million certificates. The CA announced mass revocation beginning March 4, 2020, requiring…

Continue in the Infrastructure pillar

Return to the hub for curated research and deep-dive guides.

Visit pillar hub

Latest guides

• Telecom Modernization Infrastructure Guide

  Modernise telecom infrastructure using 3GPP Release 18 roadmaps, O-RAN Alliance specifications, and ITU broadband benchmarks curated here.

• Infrastructure Resilience Guide

  Coordinate capacity planning, supply chain, and reliability operations using DOE grid programmes, Uptime Institute benchmarks, and NERC reliability mandates covered here.

• Edge Resilience Infrastructure Guide

  Engineer resilient edge estates using ETSI MEC standards, DOE grid assessments, and GSMA availability benchmarks documented here.

Coverage intelligence

Published

February 24, 2020

Coverage pillar

Infrastructure

Source credibility

91/100 — high confidence

Topics

Apache Tomcat · CVE-2020-1938 · AJP

Sources cited

3 sources (tomcat.apache.org, cisa.gov, cisecurity.org)

Reading time

6 min

Cited sources

1. Apache Tomcat CVE-2020-1938 — apache.org
2. CISA Ghostcat Alert — cisa.gov
3. CIS Apache Tomcat Benchmark — cisecurity.org