CVE-2026-24733

What it actually does

Apache Tomcat improperly accepted HTTP/0.9-style requests using methods other than GET. In affected versions, a security constraint that denied GET access to a URI but allowed HEAD could be bypassed by sending an invalid HTTP/0.9 HEAD request. The impact is limited to authorization bypass for specific Tomcat configurations where method-specific constraints treat HEAD as allowed and GET as denied for the same resource. The flaw can allow unauthorized retrieval behavior equivalent to a GET path authorization bypass in affected deployments, but does not provide code execution, privilege escalation on the host, or service-wide compromise by itself.

Why it matters to the business

Organizations running affected Apache Tomcat versions may unintentionally expose protected web resources if their applications rely on method-specific access controls that deny GET but allow HEAD. The practical risk is narrower than many remote web vulnerabilities because exploitation requires a specific security-constraint configuration and has high attack complexity, reflected by a low CVSS score and low EPSS. However, Tomcat is widely deployed in enterprise Java applications, so teams should still patch during normal vulnerability remediation cycles, especially for internet-facing applications or systems hosting sensitive content.

How an attack unfolds

An attacker first identifies an Apache Tomcat-hosted application and a URI protected by method-specific security constraints. The vulnerable configuration is one where GET requests are denied but HEAD requests are allowed for the same URI. The attacker then crafts a malformed HTTP/0.9-style request using the HEAD method, even though HTTP/0.9 only permits GET by specification. Vulnerable Tomcat versions fail to restrict HTTP/0.9 requests to GET and process the invalid HEAD request in a way that can bypass the intended GET restriction. If the application exposes sensitive or state-relevant content behind that constraint, the attacker may access or influence the protected resource contrary to policy. There is no public exploit maturity indicated and the vulnerability is not listed in CISA KEV, so current exploitation pressure appears low, but targeted probing of unusual HTTP protocol handling is plausible against exposed Tomcat services.

How to fix it

Upgrade Apache Tomcat to a fixed supported release: 11.0.15 or later for the 11.x line, 10.1.50 or later for the 10.1.x line, or 9.0.113 or later for the 9.0.x line. Older end-of-life Tomcat versions are also affected and should be migrated to a supported fixed branch rather than backported ad hoc. Review web.xml and application security constraints for method-specific rules that allow HEAD while denying GET, especially on sensitive URIs; align GET and HEAD authorization unless there is a well-justified business requirement. As a temporary mitigation, block unexpected HTTP/0.9 traffic and malformed method/protocol combinations at a reverse proxy, WAF, load balancer, or ingress controller where possible. Ensure front-end proxies do not normalize or pass through invalid HTTP/0.9 HEAD requests to Tomcat.

How to confirm the fix worked

Confirm installed Tomcat versions are 11.0.15 or later, 10.1.50 or later, or 9.0.113 or later. Verify no unsupported end-of-life Tomcat branches remain in production. Review application security constraints for URI patterns where GET is denied and HEAD is permitted; these are the configurations most relevant to this vulnerability. In a controlled test environment, attempt a normal GET, normal HEAD, and malformed HTTP/0.9-style HEAD request against representative constrained URIs and confirm authorization outcomes are consistent with policy after patching. Check reverse proxy and Tomcat access logs to ensure invalid HTTP/0.9 requests are rejected or handled safely and do not reach protected resources.

Typical attack path

1. Identify an internet-facing or reachable application served by Apache Tomcat.
2. Fingerprint the Tomcat version or infer it from headers, error pages, behavior, or dependency inventories.
3. Probe protected URIs with normal GET and HEAD requests to identify method-specific access-control differences.
4. Find a URI where GET is denied but HEAD is allowed by Tomcat security constraints.
5. Send a specification-invalid HTTP/0.9-style HEAD request to the protected URI.
6. Observe whether the request bypasses the intended GET restriction and returns unauthorized access behavior.
7. Repeat against other constrained resources if the application uses similar method-specific authorization rules.

How to detect it

Review Tomcat access logs, reverse proxy logs, WAF logs, and load balancer logs for malformed or unusual HTTP/0.9 requests, especially those using the HEAD method or targeting sensitive/protected URI patterns. Compare responses for denied GET requests versus successful or differently handled HEAD requests to the same path. Focus on requests with protocol strings such as HTTP/0.9, missing protocol fields, unusual request-line parsing, or WAF/proxy parser errors around HEAD. Investigate any 2xx or 3xx responses for HEAD requests to URIs where GET is normally 401, 403, or otherwise blocked by security constraints. If available, correlate with application audit logs for unauthorized access to protected routes, session-less requests, repeated probing of HTTP methods, and source IPs cycling through GET, HEAD, OPTIONS, TRACE, or malformed request formats. No known KEV exploitation or named threat actor activity is indicated for this vulnerability as of the provided data, so detection should focus on protocol anomaly hunting and access-control bypass attempts rather than malware-specific artifacts.

• "HEAD /" "HTTP/0.9"
• "HTTP/0.9"
• "HEAD " "HTTP/0.9"
• "GET " " 403 "
• "HEAD " " 200 "
• "HEAD " " 302 "
• "HEAD " " 401 "
• "OPTIONS "
• "TRACE "
• "Invalid method"
• "Invalid character found in method name"
• "Invalid character found in the HTTP protocol"
• "Error parsing HTTP request header"
• "org.apache.coyote.http11.Http11Processor"
• "Bad request" "HTTP/0.9"

What your security team should do

• Inventory Apache Tomcat instances, including embedded Tomcat in Java applications and appliance-like products.
• Prioritize patching internet-facing Tomcat services and applications that use web.xml security constraints or container-managed authorization.
• Upgrade to Tomcat 11.0.15+, 10.1.50+, or 9.0.113+ depending on the deployed branch.
• Review method-specific access-control rules and remove configurations that allow HEAD while denying GET unless explicitly required.
• Add WAF, reverse proxy, or ingress rules to reject HTTP/0.9 requests and malformed HEAD requests where operationally safe.
• Search historical web access logs for unusual HTTP/0.9 or HEAD requests to protected endpoints.
• Add regression tests for authorization behavior across GET, HEAD, and malformed protocol versions on sensitive routes.
• Track vendor advisories for downstream products that bundle Tomcat and apply their fixed releases when available.