CVE-2021-33193: Debian Linux HTTP/2 Proxy Vulnerability

CVE-2021-33193 Overview

CVE-2021-33193 is an HTTP Request Smuggling vulnerability affecting Apache HTTP Server versions 2.4.17 through 2.4.48. The vulnerability exists in the way mod_proxy handles HTTP/2 requests, where a crafted method sent through HTTP/2 can bypass validation checks and be forwarded, potentially leading to request splitting or cache poisoning attacks.

This vulnerability allows remote attackers to manipulate HTTP request processing by exploiting differences in how HTTP/2 requests are parsed and forwarded through the Apache proxy module. Successful exploitation could allow attackers to poison web caches, hijack user sessions, or bypass security controls.

Critical Impact

Remote attackers can bypass HTTP method validation in mod_proxy when using HTTP/2, enabling request smuggling attacks that may result in cache poisoning or unauthorized access to backend systems.

Affected Products

• Apache HTTP Server 2.4.17 to 2.4.48
• Debian Linux 10.0
• Fedora 34 and 35
• Tenable Tenable.sc
• Oracle Secure Backup
• Oracle ZFS Storage Appliance Kit 8.8

Discovery Timeline

• 2021-08-16 - CVE-2021-33193 published to NVD
• 2025-05-01 - Last updated in NVD database

Technical Details for CVE-2021-33193

Vulnerability Analysis

The vulnerability exists in the HTTP/2 request handling mechanism within Apache HTTP Server's mod_proxy module. When HTTP/2 requests are processed and forwarded to backend servers, the HTTP method validation is improperly handled, allowing malformed or crafted methods to pass through unchecked.

HTTP/2 introduces binary framing and multiplexing, which changes how request headers and methods are encoded compared to HTTP/1.1. The mod_proxy module failed to properly validate HTTP methods when converting HTTP/2 requests for proxying to backend servers. This discrepancy in validation between HTTP/2 and HTTP/1.x processing creates an opportunity for request smuggling attacks.

The vulnerability is network-accessible and requires no authentication or user interaction to exploit. Successful exploitation primarily impacts data integrity, as attackers can manipulate cached content or inject malicious requests into the request stream.

Root Cause

The root cause lies in the insufficient validation of HTTP methods when requests are received over HTTP/2 and subsequently forwarded by mod_proxy. The Apache HTTP Server's HTTP/2 implementation did not apply the same strict method validation that exists for HTTP/1.x requests, creating a validation gap that attackers could exploit.

The core issue stems from the architectural differences between HTTP/1.x text-based parsing and HTTP/2 binary framing. The proxy module's validation logic was designed primarily for HTTP/1.x request formats, and the HTTP/2 adapter did not enforce equivalent security constraints before forwarding requests.

Attack Vector

An attacker can exploit this vulnerability by sending specially crafted HTTP/2 requests through an Apache server configured with mod_proxy. The attack involves:

1. Establishing an HTTP/2 connection to the vulnerable Apache server
2. Sending a request with a malformed or specially crafted HTTP method that would normally be rejected
3. The method bypasses validation and is forwarded to the backend server via mod_proxy
4. The attacker can then perform request splitting (injecting additional requests) or cache poisoning (storing malicious responses in caches)

The fix implemented in Apache 2.4.49 introduced common parsing and validation functions (ap_parse_request_line() and ap_check_request_header()) for both HTTP/1.x and HTTP/2 requests, ensuring consistent security validation:

                                                          -*- coding: utf-8 -*-
 Changes with Apache 2.4.49
 
+  *) core: Split ap_create_request() from ap_read_request(). [Graham Leggett]
+
+  *) core, h2: common ap_parse_request_line() and ap_check_request_header()
+     code. [Yann Ylavic]
+
+  *) core: Add StrictHostCheck to allow unconfigured hostnames to be
+     rejected. [Eric Covener]
+
 Changes with Apache 2.4.48
 
   *) mod_proxy_wstunnel: Add ProxyWebsocketFallbackToProxyHttp to opt-out the

Source: GitHub HTTPD Patch

Additionally, a new StrictHostCheck directive was introduced to enhance request validation:

<directivesynopsis>
<name>StrictHostCheck</name>
<description>Controls whether the server requires the requested hostname be
             listed enumerated in the virtual host handling the request
             </description>
<syntax>StrictHostCheck ON|OFF</syntax>
<default>StrictHostCheck OFF</default>
<contextlist><context>server config</context><context>virtual host</context>
</contextlist>
<compatibility>Added in 2.5.1</compatibility>

<usage>
    <p>By default, the server will respond to requests for any hostname,
    including requests addressed to unexpected or unconfigured hostnames. 
    While this is convenient, it is sometimes desirable to limit what hostnames
    a backend application handles since it will often generate self-referential
    responses.</p>

    <p>By setting <directive>StrictHostCheck</directive> to <em>ON</em>,
    the server will return an HTTP 400 error if the requested hostname
    hasn't been explicitly listed by either <directive module="core"
    >ServerName</directive> or <directive module="core"
    >ServerAlias</directive> in the virtual host that best matches the
    details of the incoming connection.</p>

Source: GitHub HTTPD Patch

Detection Methods for CVE-2021-33193

Indicators of Compromise

• Unusual HTTP method names in proxy access logs that would normally be rejected
• Cache entries containing unexpected or malicious content
• HTTP/2 requests with malformed pseudo-headers or unusual method values
• Backend server logs showing requests with invalid HTTP methods that should have been filtered by the proxy

Detection Strategies

• Monitor Apache access logs for HTTP/2 requests with unusual or non-standard HTTP methods being proxied
• Implement web application firewall (WAF) rules to detect request smuggling patterns in HTTP/2 traffic
• Analyze cache server logs for signs of cache poisoning, such as unexpected content stored under legitimate URLs
• Deploy network intrusion detection signatures to identify HTTP/2 request smuggling attempts

Monitoring Recommendations

• Enable detailed logging for mod_proxy and mod_http2 modules to capture request method details
• Configure alerting on any HTTP 4xx/5xx errors from backend servers that may indicate request parsing issues
• Implement regular cache integrity checks to detect poisoned cache entries
• Review HTTP/2 connection metrics for anomalous patterns indicating exploitation attempts

How to Mitigate CVE-2021-33193

Immediate Actions Required

• Upgrade Apache HTTP Server to version 2.4.49 or later immediately
• If immediate patching is not possible, consider disabling HTTP/2 support (Protocols http/1.1) as a temporary mitigation
• Review and audit mod_proxy configurations for exposure to untrusted clients
• Implement strict input validation at the WAF level for HTTP methods

Patch Information

Apache has released version 2.4.49 which addresses this vulnerability through improved request parsing and validation. The patch introduces common ap_parse_request_line() and ap_check_request_header() functions that are used by both HTTP/1.x and HTTP/2 handlers, ensuring consistent validation across protocols.

Patch resources:

• GitHub HTTPD Patch
• Oracle Security Alert January 2022
• Oracle Security Alert April 2022
• Tenable Security Advisory TNS-2021-17

Workarounds

• Disable HTTP/2 support by removing h2 and h2c from the Protocols directive if HTTP/2 is not required
• Disable mod_proxy if reverse proxy functionality is not needed
• Implement strict HTTP method whitelisting at the network perimeter or WAF level
• Enable the StrictHostCheck ON directive (available in patched versions) to add additional validation

# Configuration example - Disable HTTP/2 as temporary workaround
# In httpd.conf or virtual host configuration:
# Remove h2 and h2c from Protocols directive
Protocols http/1.1

# Or explicitly disable mod_http2
# Comment out or remove:
# LoadModule http2_module modules/mod_http2.so

# If using patched version, enable strict host checking:
StrictHostCheck ON