CVE-2022-24761: Waitress HTTP Request Smuggling Flaw

CVE-2022-24761 Overview

CVE-2022-24761 is an HTTP Request Smuggling vulnerability affecting Waitress, a Web Server Gateway Interface (WSGI) server for Python 2 and 3. When Waitress versions 2.1.0 and prior are deployed behind a proxy that does not properly validate incoming HTTP requests against the RFC7230 standard, a discrepancy can occur between how Waitress and the frontend proxy interpret request boundaries. This allows attackers to smuggle malicious requests through the front-end proxy to Waitress, potentially leading to cache poisoning, session hijacking, or unauthorized access to backend resources.

Critical Impact

Attackers can exploit improper parsing of Content-Length headers and chunked encoding to smuggle HTTP requests, bypassing security controls and potentially compromising backend application integrity.

Affected Products

• Agendaless Waitress versions 2.1.0 and prior
• Debian Linux 9.0 (Stretch)
• Any deployment using Waitress behind a reverse proxy without strict RFC7230 validation

Discovery Timeline

• 2022-03-17 - CVE-2022-24761 published to NVD
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2022-24761

Vulnerability Analysis

This HTTP Request Smuggling vulnerability stems from two distinct parsing issues in Waitress that cause it to interpret HTTP requests differently than front-end proxies. The fundamental problem lies in the permissive parsing behavior that accepts non-standard input formats, creating opportunities for HTTP desynchronization attacks.

The vulnerability enables attackers to craft specially formatted HTTP requests that exploit the parsing differences between Waitress and upstream proxies. When these components disagree on where one request ends and another begins, an attacker can inject additional requests that bypass the proxy's security controls entirely.

Root Cause

The vulnerability has two root causes related to improper input validation:

1. Permissive Integer Parsing: Waitress uses Python's built-in int() function to parse numeric values in HTTP headers. This function accepts formats beyond what RFC7230 specifies, such as +10 being parsed as 10, or hexadecimal strings like 0x01 being parsed as 1. The RFC7230 standard requires that Content-Length and chunk length values contain only decimal digits.

2. Invalid Chunk Extension Handling: While Waitress does not support chunk extensions in chunked transfer encoding, it was silently discarding them without validating that they did not contain illegal characters. This allows specially crafted chunk extensions to bypass validation and cause request boundary confusion.

Attack Vector

The attack vector is network-based and requires no authentication or user interaction. An attacker sends crafted HTTP requests to a front-end proxy (such as nginx, HAProxy, or a CDN) that forwards traffic to Waitress. The malformed headers cause the proxy and Waitress to parse the request boundaries differently, allowing smuggled requests to reach the backend application.

For example, a Content-Length header containing +100 would be rejected by a standards-compliant proxy but accepted by vulnerable Waitress versions as 100. Similarly, chunk lengths specified as 0x10 (hexadecimal) would be interpreted differently by the two components.

The security patch documented in the CHANGES.txt shows the specific fixes applied:

+2.1.1
+-----
+
+Security Bugfix
+~~~~~~~~~~~~~~~
+
+- Waitress now validates that chunked encoding extensions are valid, and don't
+  contain invalid characters that are not allowed. They are still skipped/not
+  processed, but if they contain invalid data we no longer continue in and
+  return a 400 Bad Request. This stops potential HTTP desync/HTTP request
+  smuggling. Thanks to Zhang Zeyu for reporting this issue. See
+  https://github.com/Pylons/waitress/security/advisories/GHSA-4f7p-27jc-3c36
+
+- Waitress now validates that the chunk length is only valid hex digits when
+  parsing chunked encoding, and values such as ``0x01`` and ``+01`` are no
+  longer supported. This stops potential HTTP desync/HTTP request smuggling.
+  Thanks to Zhang Zeyu for reporting this issue. See
+  https://github.com/Pylons/waitress/security/advisories/GHSA-4f7p-27jc-3c36
+
+- Waitress now validates that the Content-Length sent by a remote contains only
+  digits in accordance with RFC7230 and will return a 400 Bad Request when the
+  Content-Length header contains invalid data, such as ``+10`` which would
+  previously get parsed as ``10`` and accepted. This stops potential HTTP
+  desync/HTTP request smuggling Thanks to Zhang Zeyu for reporting this issue. See
+  https://github.com/Pylons/waitress/security/advisories/GHSA-4f7p-27jc-3c36
+
 2.1.0
 -----
 

Source: GitHub Commit Changes

Detection Methods for CVE-2022-24761

Indicators of Compromise

• HTTP requests with non-standard Content-Length values containing + prefix or hexadecimal notation (e.g., Content-Length: +100 or Content-Length: 0x64)
• Chunked transfer encoding requests with malformed chunk extensions containing invalid characters
• Web server logs showing unexpected 400 Bad Request responses after patching (indicating blocked exploit attempts)
• Application logs indicating request processing anomalies or unexpected request sequences

Detection Strategies

• Deploy web application firewalls (WAF) with rules to detect and block non-RFC7230 compliant HTTP headers
• Implement log analysis to identify requests with malformed Content-Length headers or invalid chunk encoding
• Monitor for discrepancies between proxy access logs and backend application logs that may indicate smuggled requests
• Use SentinelOne Singularity Platform to detect anomalous network traffic patterns consistent with HTTP request smuggling attempts

Monitoring Recommendations

• Enable detailed HTTP request logging on both proxy and backend servers to facilitate correlation analysis
• Configure alerting for HTTP 400 responses that may indicate exploitation attempts against patched systems
• Implement network traffic inspection at the application layer to identify malformed HTTP requests
• Regularly audit Waitress version deployments across your infrastructure using software composition analysis tools

How to Mitigate CVE-2022-24761

Immediate Actions Required

• Upgrade Waitress to version 2.1.1 or later immediately across all affected deployments
• Audit all Python applications using Waitress as the WSGI server to identify vulnerable installations
• Review reverse proxy configurations to ensure strict RFC7230 validation is enabled
• Implement network segmentation to limit exposure of backend WSGI servers

Patch Information

The vulnerability has been patched in Waitress version 2.1.1. The patch implements strict validation for Content-Length headers, chunk lengths, and chunk extensions to ensure RFC7230 compliance. The fix is available through the standard package managers.

The version bump from 2.1.0 to 2.1.1 is shown in the setup.cfg changes:

 [metadata]
 name = waitress
-version = 2.1.0
+version = 2.1.1
 description = Waitress WSGI server
 long_description = file: README.rst, CHANGES.txt
 long_description_content_type = text/x-rst

Source: GitHub Commit Changes

For additional information, see the GitHub Security Advisory GHSA-4f7p-27jc-3c36, the GitHub Release v2.1.1, and the Debian Security Advisory DSA-5138.

Workarounds

• Configure front-end proxies to enforce strict RFC7230 validation on all incoming HTTP requests before forwarding to Waitress
• Implement request header sanitization at the proxy layer to reject Content-Length headers containing non-digit characters
• Enable strict chunked encoding validation on reverse proxies that support this feature
• Consider temporarily placing a more hardened HTTP server (such as nginx) in front of Waitress with strict request validation enabled

# Upgrade Waitress using pip
pip install --upgrade waitress>=2.1.1

# Verify installed version
pip show waitress | grep Version

# For Debian-based systems with system packages
apt-get update && apt-get install python3-waitress