What Happened
On February 20, 2020, CNVD published details of CVE-2020-1938—a vulnerability affecting Apache Tomcat versions 6 through 9. Discovered by Chaitin Tech on January 3rd, the flaw exploited the AJP (Apache JServ Protocol) Connector, which is enabled by default on port 8009.
The attack was straightforward: an attacker could send crafted AJP messages to read arbitrary files from the server or, under specific conditions, upload and execute malicious code. No authentication was required. If your Tomcat instance was reachable on port 8009, you were exposed.
Timeline
- January 3, 2020: Chaitin Tech discovers the vulnerability during security research.
- February 20, 2020: CNVD publishes vulnerability details as CVE-2020-1938.
- February 24, 2020: Apache releases patched versions for Tomcat 7.0.100, 8.5.51, and 9.0.31.
- Ongoing: Organizations running older Tomcat versions or Spring Boot applications with default configurations remain vulnerable unless they've applied configuration changes or patches.
Which Controls Failed or Were Missing
1. Network Segmentation
The AJP Connector was designed for internal communication between a web server and Tomcat. It should never be exposed to untrusted networks. Yet many deployments left port 8009 accessible from the internet or from broader network segments than necessary.
Control gap: No network-level restriction on AJP port access. Firewall rules were either absent or too permissive.
2. Default Configuration Hardening
Tomcat shipped with the AJP Connector enabled on port 8009 by default. Organizations that deployed Tomcat without reviewing server.xml inherited this exposure immediately.
Control gap: No configuration review process before production deployment. No baseline security configuration standard for application servers.
3. Vulnerability Scanning
The AJP Connector vulnerability existed in all Tomcat versions, but many vulnerability scanners didn't flag it until after CVE-2020-1938 was published. Organizations relying solely on automated scanning missed the exposure.
Control gap: Vulnerability management focused on known CVEs rather than configuration weaknesses. No manual review of exposed services.
4. Patch Management
Between the January 3rd discovery and February 24th patch release, organizations had no vendor-supplied fix. Even after patches became available, deployment timelines varied widely. Spring Boot applications required framework updates, not just Tomcat patches, adding complexity.
Control gap: No process for emergency patching. No testing pipeline that could validate patches quickly. No compensating controls strategy for zero-day windows.
What the Relevant Standards Require
PCI DSS v4.0.1
Requirement 2.2.1: Configuration standards are defined and implemented for all system components.
You need documented configuration standards for every system type in your environment. For Tomcat, this means specifying which connectors to enable, which ports to expose, and which settings to modify from defaults.
Requirement 6.3.3: Security vulnerabilities are identified and addressed.
This covers both patching and compensating controls. When Apache released patches on February 24th, your vulnerability management process should have flagged affected systems and initiated deployment. If you couldn't patch immediately, you needed documented compensating controls—in this case, firewall rules blocking port 8009.
Requirement 11.3.2: Internal vulnerability scans are performed.
Your scanning should identify exposed services, not just known CVEs. An internal scan that sees port 8009 open should raise questions, even before CVE-2020-1938 existed.
OWASP ASVS v4.0.3
V1.14.2: All components are up to date with proper security configuration.
This requirement explicitly calls out both patching and configuration. Ghostcat violated both: the vulnerability existed in the code, but the default configuration made it exploitable.
V14.2.3: HTTP strict transport security headers are included on all responses.
While not directly related to Ghostcat, this requirement reflects the broader principle: security depends on configuration, not just code. Headers, connectors, ports—all must be explicitly set.
NIST 800-53 Rev 5
CM-6: Configuration Settings: Organizations must establish and document configuration settings for their information systems.
Your Tomcat deployment should have a configuration baseline that explicitly disables unused connectors. "We used the default" isn't a configuration decision—it's the absence of one.
SI-2: Flaw Remediation: Organizations must identify, report, and correct system flaws.
The 51-day window between discovery and patch release tested every organization's flaw remediation process. Could you identify affected systems? Did you have a testing pipeline? Could you deploy to production on an accelerated timeline?
Lessons and Action Items for Your Team
1. Build Configuration Baselines Before Deployment
Create a server.xml template for Tomcat that disables the AJP Connector unless you explicitly need it. If you do need AJP for Apache HTTP Server integration, bind it to localhost or a specific internal IP—never to 0.0.0.0.
Action: Document your Tomcat configuration standard in your CM-6 compliance artifacts. Include specific XML snippets, not just principles.
2. Treat Default Configurations as Vulnerabilities
When you deploy any application server, database, or framework, assume the defaults are wrong. Spring Boot's embedded Tomcat doesn't enable AJP by default, but many configuration decisions optimize for ease of use, not security.
Action: Add a configuration review step to your deployment checklist. Before any new service goes to production, document which defaults were changed and why.
3. Scan for Services, Not Just CVEs
Your vulnerability scanner should inventory exposed ports and services, then compare that inventory to your documented architecture. Port 8009 listening on a web server should trigger an alert, whether or not a CVE exists.
Action: Configure your scanner to flag unexpected services. Build a whitelist of approved ports for each system type.
4. Build a Compensating Controls Playbook
You can't always patch immediately. Testing takes time. Change windows are limited. You need documented procedures for temporary risk reduction.
For Ghostcat, the compensating control was simple: block port 8009 at the firewall. But you need to know that option exists, have the firewall access to implement it, and document the control for auditors.
Action: For each critical application, document what compensating controls you could deploy if a zero-day emerged tomorrow. Test that you can actually implement them—firewall rules, WAF policies, network segmentation—within hours, not days.
5. Inventory Your Tomcat Deployments Now
You can't patch what you don't know exists. Tomcat runs embedded in Spring Boot applications, standalone on application servers, and inside commercial products. Your asset inventory needs to capture all of them.
Action: Query your CMDB for Tomcat instances. Scan for port 8009 listeners. Check Spring Boot applications for their embedded Tomcat versions. Build a matrix of version numbers and patch status.
Ghostcat didn't require sophisticated exploitation. It required a default configuration and an exposed port. That's the lesson: your security posture depends as much on what you disable as what you enable.
