SecPod

Learn Search

Search across all Learn content

← Back to Expressions & POVs
Apache Tomcat servers vulnerable to Ghostcat flaw

Apache Tomcat servers vulnerable to Ghostcat flaw

Mar 1, 2020By Vidita V Koushik3 min read

A critical vulnerability named Ghostcat was recently discovered in Apache Tomcat Servers. Apache Tomcat is a software used to deploy Java Servlets and JSPs. This vulnerability resides in Tomcat for more than a decade now. To prevent such vulnerabilities, a good vulnerability management software would be a great asset.

Ghostcat, tracked as CVE-2020-1938, was discovered in Tomcat AJP protocol by researchers at Chaitin Tech. Tomcat AJP has a configuration with two connectors: HTTP Connector and AJP Connector. Tomcat AJP protocol connector is a component that communicates with a web connector via the AJP protocol.

This flaw allows attackers to read or include any files in the web application directories of Tomcat. The impact is much more severe in cases where the application allows the files to upload. An attacker can upload a malicious file, and then include it using the Ghostcat vulnerability. This could result in the execution of malicious code. Vulnerability Management Tool can prevent such attacks.

A number of researchers have published proofs-of-concept(1, 2, 3, 4, 5) for CVE-2020-1938. The figure below shows the disclosure of data present in the web.xml file on a vulnerable Apache Tomcat Server.


Fig. Disclosure of sensitive data in vulnerable Apache Tomcat server

Affected Products

Apache Tomcat version 6.x, 7.x before 7.0.100, 8.x before 8.5.51 and 9.x before 9.0.31.

The default configuration on Apache Tomcat is vulnerable. Specifically, Ghostcat vulnerability can be exploited when the AJP Connector is enabled and this allows access to the AJP Connector service port. The AJP Connector is enabled by default and listens on port 8009.

How to check if the AJP connector is working in the server environment?

1) Check if any usage of cluster or reverse proxy is present.
2) Also, check if the cluster or reverse server is communicating with the Tomcat AJP Connector service.

If either is true, then the AJP connector is in use.

Impact

An attacker can execute malicious code and also read sensitive information from the configuration files and source code files of all web applications which run on Tomcat.

Solution

Apache has released fixes for this vulnerability in Tomcat.

If the AJP connector service is not in use:

If the AJP connector working is incorrect in the application, then the rectification of the vulnerability is by directly upgrading Apache Tomcat to version 7.0.100, 8.5.51, or 9.0.31.

In case the handling of the upgrade goes wrong, Chaitin advises following the steps below to disable the AJP Connector directly, or change its listening address to the localhost:

1. Edit <CATALINA_BASE>/conf/server.xml?, find the following line (<CATALINA_BASE> is the Tomcat work directory):

<Connector port=”8009″ protocol=”AJP/1.3″ redirectPort=”8443″ />

2. Comment it out(or just delete it):

<!–<Connector port=”8009″ protocol=”AJP/1.3″ redirectPort=”8443″ />–>

3. Save the edit, and then restart Tomcat.

The recommendation is to use firewalls to prevent untrusted sources from accessing the Tomcat AJP Connector service port.

If the AJP connector service is in use:

If the AJP connector service is in use, then  recommended to follow the steps below:

1. Upgrade Tomcat to version 7.0.100, 8.5.51, or 9.0.31, and then configure the “secret” attribute for the AJP Connector to set AJP protocol authentication credentials.
For example:<Connector port=”8009″ protocol=”AJP/1.3″ redirectPort=”8443″ address=”YOUR_TOMCAT_IP_ADDRESS” secret=”YOUR_TOMCAT_AJP_SECRET” />

2. If the upgrade is not possible, the recommendation is to configure the “requiredSecret” attribute for the AJP Connector to set AJP protocol authentication credentials.
For example:<Connector port=”8009″ protocol=”AJP/1.3″ redirectPort=”8443″ address=”YOUR_TOMCAT_IP_ADDRESS” requiredSecret=”YOUR_TOMCAT_AJP_SECRET” />

SanerNow detects and reports this vulnerability. Download SanerNow and keep your systems updated and secure.

Featured Posts

Open Continuous Cloud Security: The Remediation Operating Model
Continuous Cloud Remediation

Point of View

Continuous Cloud Security: The Remediation Operating Model

Oct 18, 2026

Open What Is a Kubernetes Network Policy?
What Is a Kubernetes Network Policy?

Point of View

What Is a Kubernetes Network Policy?

A Kubernetes network policy controls incoming and outgoing connections between Pods and other network destinations. The article explains how ingress and egress rules work, why default network access can create security risks, and how to configure and verify traffic restrictions. It also covers common policy mistakes and how Saner COSP's COAE and COPM modules support Kubernetes exposure visibility and configuration assessment.

Oct 16, 2026

Open Hybrid Cloud Security for Kubernetes Across Standalone, On-Prem, and Managed Clusters
Hybrid Cloud Security for Kubernetes Across Standalone, On-Prem, and Managed Clusters

Point of View

Hybrid Cloud Security for Kubernetes Across Standalone, On-Prem, and Managed Clusters

Hybrid cloud security for Kubernetes involves managing security risks across standalone, on-premises, and managed clusters. The blog explains the differences between Amazon EKS, Microsoft AKS, and Google GKE, common security challenges, and practical steps for maintaining consistent security controls. It also covers how Saner COSP helps teams assess configurations, manage access, prioritize risks, and track remediation across Kubernetes environments.

Oct 16, 2026

Open Excellence Is a Choice
Excellence Is a Choice

Point of View

Excellence Is a Choice

Oct 14, 2026