Apache Tomcat vulnerabilities recur across categories like request smuggling, path traversal, denial of service, and information disclosure, largely because Tomcat's Coyote connector sits directly on the HTTP request path for a huge share of Java web applications and has to correctly parse untrusted, attacker-controlled traffic every time. If you have ever seen Apache-Coyote/1.1 in a Server response header, that is the HTTP connector component of Tomcat announcing itself, and it is worth understanding what it does and why it shows up so often in vulnerability scans.
This post covers what Coyote actually is, the vulnerability classes that have recurred across Tomcat's history, and how to keep a Tomcat deployment reasonably safe.
What is Apache Coyote, and why does it matter for security?
Coyote is Tomcat's HTTP connector, the component responsible for accepting incoming HTTP and AJP connections, parsing the request line and headers, and handing the parsed request off to Tomcat's servlet container for processing. It is effectively the first piece of code that touches every byte of an incoming request, which makes it a high-value target for parsing-related vulnerabilities: anything that mishandles a malformed header, an unusual chunked-encoding sequence, or a boundary case in request-line parsing can potentially be turned into a request smuggling or denial-of-service issue.
Seeing apache-coyote/1.1 vulnerabilities flagged in a scan report generally means the scanner has fingerprinted the connector version from response headers or banner information and matched it against known CVEs for that Tomcat release, since Coyote's version tracks the overall Tomcat version rather than being versioned independently.
What vulnerability classes have recurred across Tomcat's history?
A few categories show up repeatedly across Tomcat's long history. Path traversal and information disclosure issues have appeared where request URI normalization did not correctly handle certain encoded or malformed paths, occasionally allowing access to files or resources outside the intended web application directory. Request smuggling and desync issues have appeared where Tomcat's interpretation of ambiguous or conflicting Content-Length and Transfer-Encoding headers diverged from a front-end proxy's interpretation, which can let an attacker smuggle a second request past security controls sitting in front of Tomcat. Denial-of-service issues have appeared where specially crafted requests could consume excessive memory or CPU during parsing.
One of the more widely known Tomcat vulnerabilities is Ghostcat (CVE-2020-1938), disclosed in 2020, which affected the AJP connector rather than the HTTP connector directly. It allowed an attacker with network access to the AJP port to read arbitrary files from the web application, and in some configurations could be escalated further. It is a good illustration of the general pattern: a connector-level parsing or protocol-handling flaw, reachable before any application-level authentication runs, with a severity determined largely by what the connector exposes by default.
Why do these vulnerabilities disproportionately affect the connector layer?
Application-level vulnerabilities in a Java web app usually require the request to first pass through the servlet container's parsing and routing logic successfully. Connector-level vulnerabilities skip that step entirely, since they exploit the parsing logic itself, before your application code, your authentication filters, or your framework's routing ever run. That is what makes tomcat vulnerabilities at the connector layer disproportionately severe relative to their apparent simplicity: a malformed header or an unexpected protocol sequence can sometimes bypass every control your application team built, because the vulnerable code executes before those controls are ever reached.
This is also why connector vulnerabilities so often affect availability and information disclosure specifically, rather than authentication bypass in the traditional sense. The connector's job is limited to parsing and routing, so the blast radius of a bug there tends to be scoped to what parsing-stage code can access: memory, file paths, or the ability to desynchronize how two systems interpret the same request stream.
How should you actually manage Tomcat vulnerability risk?
Keep Tomcat on a currently supported major version and apply security releases promptly, since the project maintains multiple branches and patches connector-level issues on the same schedule as application-container issues. Disable the AJP connector entirely if you are not using it, which was the direct mitigation for Ghostcat and remains good general hygiene, since an unused connector is pure attack surface with no offsetting benefit. If AJP is required, bind it to localhost or an internal network only, and set a shared secret so unauthenticated requests are rejected outright.
For request smuggling risk specifically, make sure Tomcat and any reverse proxy or load balancer in front of it agree on how ambiguous Content-Length and Transfer-Encoding combinations are handled, and prefer terminating HTTP/1.1 keep-alive connections consistently rather than mixing HTTP versions across the proxy boundary in ways that create parsing ambiguity.
From a scanning standpoint, an SCA scan that fingerprints the Tomcat and Coyote version in your dependency or infrastructure inventory is the fastest way to know whether you are exposed to a disclosed CVE, and a DAST scan against a running deployment can confirm whether a specific connector-level issue is actually reachable in your configuration, since exposure often depends heavily on network placement and connector configuration rather than version alone.
FAQ
Is Apache-Coyote/1.1 in my response headers itself a vulnerability?
No, it is just a banner identifying the connector and its protocol version. It becomes relevant to security only insofar as it lets a scanner or an attacker infer which Tomcat version you are running and check it against known CVEs.
Should I hide the Coyote version string to reduce risk?
Suppressing version banners is a reasonable defense-in-depth step, but it does not fix any underlying vulnerability, it only makes automated fingerprinting slightly harder. Patching remains the actual fix.
Is the AJP connector still necessary in modern deployments?
Most modern deployments terminate HTTP directly or sit behind a reverse proxy that talks HTTP, not AJP, to Tomcat. Unless you specifically integrate with a legacy web server over AJP, it is usually safe and advisable to disable it.
How often are new Tomcat CVEs disclosed?
Tomcat receives security-relevant patches on a fairly regular cadence as part of its ongoing maintenance releases. Subscribing to the Apache Tomcat security announcements and tracking your deployed version against them is the most reliable way to stay current.