CVE-2026-24733: Apache Tomcat HTTP/0.9 Flaw Enables Security Constraint Bypass via Crafted HEAD Requests

Apache Tomcat – HTTP/0.9 Security Constraint Bypass

CVE ID: CVE-2026-24733
Product: Apache Tomcat
Vulnerability Type: Security Constraint Bypass / Improper Input Validation
CWE: CWE-20 (Improper Input Validation)
Severity (Vendor): Low
CVSS Score: Not officially published at the time of writing
Attack Vector: Network
Authentication Required: No
User Interaction: No
Privileges Required: None
Exploit Availability: No confirmed public exploit kit; easily reproducible in lab
Impact: Access control bypass under specific configuration conditions

Overview

In certain versions of Apache Tomcat, request parsing logic allowed HTTP/0.9-style requests to be processed with methods other than GET. This behavior created a condition where security constraints configured to block GET requests but allow HEAD requests could be bypassed.

The issue arises from the way legacy HTTP/0.9 request formats were handled internally. HTTP/0.9 is an obsolete protocol format that does not include the HTTP version string (e.g., HTTP/1.1) in the request line. Under normal circumstances, HTTP/0.9 should only support simple GET requests. However, in vulnerable versions, Tomcat accepted other methods (such as HEAD) in HTTP/0.9 format.

Because of this, a crafted request could reach protected resources that were otherwise restricted via standard HTTP method enforcement.

Affected Versions

The following Apache Tomcat versions are affected:

9.0.0.M1 through 9.0.112
10.1.0-M1 through 10.1.49
11.0.0-M1 through 11.0.14

Fixed Versions

The issue has been corrected in:

9.0.113
10.1.50
11.0.15

Official Patch / Upgrade Links

Upgrading to the latest stable release is the recommended and permanent remediation.

Technical Root Cause

The vulnerability exists due to improper validation of HTTP protocol versions during request parsing.

Under normal HTTP/1.1 behavior, a request line looks like:

HEAD /admin HTTP/1.1

In HTTP/0.9 format, the request line appears as:

GET /admin

The issue occurs because Tomcat accepted requests structured like:

HEAD /admin

(without HTTP/1.x present).

When such a request was processed, it entered the HTTP/0.9 code path but still retained the HEAD method. If security constraints were configured to:

Deny GET
Allow HEAD

the request was evaluated as a valid HEAD request and granted access, even though equivalent GET access would have been denied.

This represents a method validation flaw within legacy protocol handling logic.

Conditions Required for Exploitation

Exploitation requires all of the following:

A vulnerable Tomcat version is in use.
Security constraints differentiate between GET and HEAD.
HTTP/0.9-style requests are accepted by the connector.
The attacker can directly communicate with the Tomcat service (no proxy normalizing requests).

If any of these conditions are not met, exploitation becomes unlikely.

Impact Assessment

This vulnerability does not allow:

Remote code execution
Arbitrary file upload
Direct data modification

It may allow:

Unauthorized resource access
Bypass of method-based restrictions
Exposure of sensitive endpoints

The actual business impact depends entirely on how method-based constraints are configured in the application.

Proof of Concept (Educational)

The vulnerability can be demonstrated in a controlled lab.

Example Using Netcat

printf 'HEAD /restricted-path\r\n' | nc target-server 80

If the server responds with resource headers or access is granted where GET would fail, the issue is present.

Raw Socket Example

HEAD /admin

(no HTTP version included)

This must be sent as a raw TCP request without appending HTTP/1.1.

cURL Test

Modern curl enforces HTTP versions. However, manual telnet/netcat testing is more reliable for reproducing the condition.

Exploitability Analysis

The exploitation complexity is low because:

No authentication is required.
No special tooling is required.
The request format is simple.

However, real-world impact is limited due to:

Rare configurations that allow HEAD but deny GET.
Modern reverse proxies often rejecting HTTP/0.9 requests.

No verified public exploit modules in common frameworks are currently associated with this CVE.

Detection Guidance

Log Sources to Monitor

Tomcat access logs (access_log.*)
Catalina logs
Reverse proxy logs (Nginx, Apache HTTPD)
WAF logs
Network IDS/IPS logs
Full packet capture (if available)

Indicators of Exploitation

HEAD requests to sensitive paths.
Requests missing HTTP/1.x in the request line.
Unexpected 200 responses to HEAD where GET normally fails.
Discrepancies between proxy and backend logs.

Network Detection Rule

alert http any any -> any 80 (
msg:"Possible HTTP/0.9 HEAD request - Tomcat bypass attempt";
flow:to_server,established;
content:"HEAD ";
depth:5;
pcre:"/^HEAD\s+\/[^\r\n]*\r\n(?!.*HTTP\/)/smi";
sid:900001;
rev:1;
)

Network Detection Rule

alert tcp any any -> $HOME_NET 80 (
msg:"HTTP/0.9 non-GET method attempt";
flow:established,to_server;
content:"HEAD ";
depth:5;
pcre:"/HEAD [^\r\n]*(\r\n)(?!.*HTTP\/)/smi";
sid:900002;
rev:1;
)

SIEM Detection Queries

Splunk Query

index=web_logs method=HEAD
| search uri_path IN ("/admin","/config","/secure","/internal")
| stats count by src_ip, uri_path, status

Detects suspicious HEAD access to restricted endpoints.

Elastic (KQL)

http.request.method : "HEAD" and
url.path : ("/admin" or "/secure" or "/config")

Generic Log Grep

grep '"HEAD ' access_log* | grep -E '/admin|/secure|/internal'

Hardening Recommendations

Upgrade to patched versions immediately.
Disable support for HTTP/0.9 if not required.
Normalize traffic through a reverse proxy.
Avoid relying solely on method-based restrictions for access control.
Implement WAF rule to reject requests without HTTP/1.x.
Apply network segmentation for administrative endpoints.

Mitigation If Upgrade Is Delayed

Deploy WAF rule blocking request lines without HTTP/.
Restrict direct internet access to Tomcat connectors.
Monitor for abnormal HEAD request spikes.
Enforce strict method validation at proxy layer.

Incident Response Actions

If exploitation is suspected:

Preserve web server logs.
Identify unusual HEAD access.
Validate accessed endpoints for sensitive exposure.
Patch immediately.
Review application security constraints.
Rotate credentials if protected resources were exposed.

Risk Summary

Although rated low severity by vendor classification, the issue can become meaningful in environments relying on method-specific restrictions. It does not provide direct system compromise but can weaken perimeter enforcement if misconfigured.

The safest and most reliable solution remains upgrading to the fixed Tomcat release.