CVE-2024-49768

What it actually does

Race condition in request handling allows a pipelined secondary HTTP request to be processed by a worker thread after the primary request triggers a parsing error and the connection should have been closed, when channel_request_lookahead is enabled.

Why it matters to the business

Organizations using the affected WSGI server with lookahead enabled face a risk of unintended request processing that bypasses connection closure logic, potentially leading to resource misuse or exposure of application behavior; default configuration leaves most deployments unaffected.

How an attack unfolds

An attacker sends an initial request exactly recv_bytes long that causes a parsing failure, immediately followed by a pipelined secondary request; with lookahead enabled the server begins error response handling while queuing and servicing the secondary request on the same connection that should have closed.

How to fix it

Upgrade pylons/waitress to the fixed commit ae949bb428e50cf04152db56460f31c1e6d3a2a9 (version 3.0.1) or later; for affected Moodle packages on Ubuntu 16.04 and 18.04 upgrade to 3.0.3+dfsg-0ubuntu1 or newer; as a workaround ensure channel_request_lookahead remains disabled (default value of 0).

How to confirm the fix worked

Verify installed Waitress version is 3.0.1 or newer via package metadata or pip show; confirm channel_request_lookahead setting is 0 in configuration; test request handling with a malformed request followed by pipelined traffic to ensure connection closure occurs as expected.

Typical attack path

1. Craft and send first HTTP request of exactly recv_bytes length designed to trigger a parsing error
2. Immediately pipeline a secondary valid request using HTTP pipelining
3. Observe processing of the secondary request despite the error state on the primary request
4. Continue interaction with the application via the worker thread handling the secondary request

How to detect it

Review application and WSGI server logs for sequences of parsing errors immediately followed by successful processing of subsequent pipelined requests on the same connection; monitor for unexpected worker thread activity after error responses.

What your security team should do

• Immediately audit all deployments for enabled channel_request_lookahead and disable where found
• Prioritize upgrade of Waitress to 3.0.1 across all Python WSGI environments
• Update affected Moodle packages on Ubuntu 16.04/18.04 to 3.0.3+dfsg-0ubuntu1
• Add version checks for Waitress to regular dependency scanning and CI pipelines