Web

The Case of the Missing Carriage Return: Unpacking CVE-2025-43859 in Python's h11

Robert Morgan

Robert Morgan

— 7 min read

Hey folks, gather 'round the virtual campfire! Today, we're diving into CVE-2025-43859, a sneaky vulnerability lurking in older versions of h11, a popular Python library for handling HTTP/1.1. While it might seem like a minor parsing quirk at first glance, this bug can team up with other misconfigurations to create a classic web security nightmare: HTTP Request Smuggling. Grab your favorite beverage, and let's unravel this together.

TL;DR / Executive Summary

What's the issue? CVE-2025-43859 describes a vulnerability in the Python h11 library (versions prior to 0.16.0). The library was too lenient when parsing the end of chunks in HTTP/1.1 Chunked Transfer-Encoding, accepting any two bytes instead of strictly requiring the \r\n (CRLF) sequence.
Who's affected? Applications using h11 versions < 0.16.0 behind a reverse proxy or other intermediary that has its own, different bug in parsing chunked encoding (specifically, reading past the chunk data until it finds a CRLF).
What's the impact? This discrepancy in parsing between h11 and a buggy proxy can lead to HTTP Request Smuggling (CWE-444). Attackers could potentially bypass security controls enforced by the proxy, poison web caches, or even hijack user sessions. The severity depends heavily on the specific proxy bug and application architecture, but the potential impact is significant.
How to fix it? Upgrade h11 to version 0.16.0 or later. Alternatively, ensure your proxy correctly parses chunked encoding according to RFC specifications.

Introduction: The Subtle Art of HTTP Parsing

Imagine HTTP messages as letters being passed between systems. Usually, they follow a strict format, like addressing an envelope correctly. HTTP/1.1 introduced "Chunked Transfer-Encoding" – a way to send data in pieces, like sending a long letter in multiple, numbered envelopes. Each envelope (chunk) says how much data it contains, followed by the data itself, and crucially, ends with a specific marker: \r\n (Carriage Return, Line Feed - CRLF).

The h11 library is like a meticulous mail sorter for Python applications, designed to handle these HTTP messages correctly. It's used by popular frameworks and tools like uvicorn, httpx, and starlette. But what happens when the mail sorter gets slightly too relaxed about the rules? That's where CVE-2025-43859 enters the picture. This isn't just an academic curiosity; when combined with other common proxy misconfigurations, it opens the door for attackers to slip malicious requests past defenses. If you're running Python web services, especially behind proxies, this one deserves your attention.

Technical Deep Dive: Where h11 Went Wrong

The heart of CVE-2025-43859 lies in how h11 (before version 0.16.0) handled the termination of data chunks in a chunked-encoded HTTP body.

According to the HTTP/1.1 standard (RFC 7230, Section 4.1), each chunk looks like this:

chunk-size [ chunk-ext ] CRLF
chunk-data CRLF

The critical part here is the CRLF after the chunk-data. h11's job is to read the chunk-size, read exactly that many bytes of chunk-data, and then verify and consume the trailing CRLF.

The Bug: Versions of h11 up to 0.14.0 (and implicitly through 0.15.x as the fix landed in 0.16.0) had a flaw in the ChunkedReader class. Instead of strictly checking for \r\n after the chunk data, it essentially did this:

  1. Read chunk-size.
  2. Read CRLF.
  3. Read chunk-size bytes of chunk-data.
  4. Discard the next two bytes, whatever they are.

See the problem? It didn't validate that those last two bytes were actually \r\n. Any two bytes would do! Let's call this "Parser A".

The Chain Reaction: By itself, this bug is mostly harmless. An application using only h11 would likely just process slightly malformed requests without issue. However, the danger arises when h11 is used as a backend server behind a reverse proxy (like Nginx, HAProxy, or others) that has a different parsing bug.

Consider a hypothetical buggy proxy ("Parser B") that handles chunked encoding like this:

  1. Read chunk-size.
  2. Read CRLF.
  3. Read chunk-size bytes of chunk-data.
  4. Keep reading data until it finds a CRLF. (This bug existed in the pound proxy, for example, if using a generic "read until newline" function).

Now we have two systems looking at the same stream of bytes but interpreting it differently. This is the classic setup for HTTP Request Smuggling (also known as Desynchronization).

Attack Vector & Business Impact:

Imagine an attacker sends a specially crafted request through the buggy proxy (Parser B) to the vulnerable h11 backend (Parser A).

  • Bypassing Security Controls: The proxy might see one harmless request, while h11 sees that request plus a second, smuggled request hidden within the first one's body (because h11 stopped reading earlier than the proxy). This smuggled request could target sensitive endpoints the proxy was supposed to block.
  • Session Hijacking: If the proxy concatenates requests from different users onto the same backend connection (common for performance), the smuggled request prefix from Attacker A could be prepended to Victim B's legitimate request. h11 might then interpret part of Victim B's request (like their session cookie) as part of Attacker A's smuggled request body, potentially leaking sensitive data.
  • Web Cache Poisoning: A smuggled request could trick the proxy or backend into caching malicious content under a legitimate URL.

Think of it like two people reading a message written with ambiguous spacing. One person reads "SEND TEN DOLLARS", while the other reads "SEND TENDOLLARS" (which might mean something completely different in their system). This difference in interpretation is what attackers exploit.

Proof of Concept (Simplified Example)

Let's use the example from the advisory to illustrate the desynchronization. Assume \r\n is used for all line breaks.

Attacker sends:

POST /login HTTP/1.1
Host: vulnerable-app.com
Transfer-Encoding: chunked

5\r\n
AAAAAXX\r\n  <-- h11 stops reading chunk data here, discards 'XX'
1\r\n        <-- Proxy keeps reading until here, sees 'XX\r\n1' as part of the chunk
B\r\n
0\r\n
GET /admin HTTP/1.1\r\n <--- Smuggled Request
Host: vulnerable-app.com\r\n
Evil-Header: BadStuff\r\n
\r\n

How Parser B (Buggy Proxy) sees it:

  1. Reads chunk size 5. Reads AAAAA. Keeps reading until \r\n. Sees AAAAAXX.
  2. Reads chunk size 1. Reads B. Reads trailing \r\n.
  3. Reads chunk size 0. Reads trailing \r\n.
  4. Sees the end of the request. It forwards what it thinks is one complete request with body AAAAAXXB to the backend. It leaves the GET /admin... part waiting in the buffer for the next request on this connection.

How Parser A (Vulnerable h11 < 0.16.0) sees it:

  1. Reads chunk size 5. Reads AAAAA. Discards the next two bytes (XX).
  2. Reads chunk size 1. Reads B. Discards the next two bytes (\r\n).
  3. Reads chunk size 0. Reads trailing \r\n. Sees the end of the first request. The body it parsed is AAAAAB.
  4. Immediately starts parsing the next request from the stream: GET /admin HTTP/1.1...

The Result: The proxy thought it was sending one request for /login. The h11 backend saw that request and a second, unauthorized request for /admin that bypassed any proxy-level checks for /admin. Ouch.

Mitigation and Remediation

Fixing this requires breaking the chain reaction – either fixing the lenient parser (h11) or the overly-greedy parser (the proxy).

  1. Upgrade h11 (Recommended): The primary fix is to update h11 to version 0.16.0 or later.

    pip install --upgrade h11
# or if using a dependency manager like poetry or pipenv
# poetry update h11
# pipenv update h11

    Verify the installed version:

    pip show h11

    Ensure the version is 0.16.0 or higher.

  2. Fix the Proxy: Ensure your reverse proxy correctly implements RFC 7230's rules for chunked encoding. This might involve updating the proxy software or adjusting its configuration if it offers different parsing modes. This is crucial anyway, as other backend systems might also be vulnerable to desync attacks if the proxy is buggy.

  3. Patch Analysis (What changed in h11 0.16.0?):
    The fix, primarily in commit 114803a, modifies the ChunkedReader in h11/_readers.py.

    • Before: The code maintained self._bytes_to_discard as an integer (initially 2). After reading chunk data, it would simply discard that many bytes from the buffer.
      # Old logic (simplified)
if self._bytes_to_discard > 0:
    data = buf.maybe_extract_at_most(self._bytes_to_discard)
    # ... null check ...
    self._bytes_to_discard -= len(data)
    # ... loop if not fully discarded ...
    • After: The code now stores self._bytes_to_discard as a byte string, specifically b"\r\n". It then explicitly compares the incoming bytes against the expected sequence.
      # New logic (simplified) - in h11 v0.15.0, released before v0.16.0
if self._bytes_to_discard: # Now checks if the byte string is non-empty
    data = buf.maybe_extract_at_most(len(self._bytes_to_discard))
    # ... null check ...
    if data != self._bytes_to_discard[:len(data)]: # Compare bytes!
        raise LocalProtocolError("malformed chunk footer...")
    self._bytes_to_discard = self._bytes_to_discard[len(data):] # Slice remaining expected bytes
    # ... loop if not fully matched ...

    This change ensures h11 strictly enforces the \r\n requirement after chunk data, rejecting malformed requests instead of silently accepting them with incorrect terminators. This breaks the desynchronization condition. Note: The advisory mentions the fix in 0.15.0, but the global advisory and versioning suggest 0.16.0 is the first fully patched release incorporating this. Always aim for the latest patched version.

  4. Verification: After patching, consider using request smuggling detection tools (like Burp Suite's Scanner or specialized scripts) against your staging environment to confirm that the desynchronization is no longer possible.

Timeline

  • Discovery Date: January 9, 2025 (Reported by Jeppe Bonde Weikop)
  • Vendor Notification: January 9, 2025 (Implied)
  • Patch Development: Commits addressing the issue appeared, leading to the fix. (e.g., commit 114803a)
  • Patch Availability: Fixed in version h11 0.16.0 (Release date precedes public disclosure)
  • Public Disclosure Date: April 24, 2025 (via GitHub Advisories)

Lessons Learned

This CVE serves as a great reminder of several key security principles:

  1. Strict Protocol Adherence is Crucial: Parsers should be strict. Lenient parsing ("be liberal in what you accept") might seem user-friendly, but it often creates ambiguities that attackers can exploit, especially in security-sensitive contexts like HTTP processing.
  2. The Danger of Parser Differentials: Whenever two different systems parse the same data stream (like a proxy and a backend server), any subtle difference in their parsing logic can potentially lead to desynchronization attacks like request smuggling. Test your stack for consistency!
  3. Defense in Depth: While upgrading h11 is the direct fix, ensuring your proxy is also correctly configured and up-to-date provides an additional layer of defense against this and other potential desync vulnerabilities.

Key Takeaway: Even seemingly minor deviations from standards, like accepting XX instead of \r\n, can cascade into serious vulnerabilities when interacting with the complexities of modern web architectures. Always validate your inputs strictly!

References and Further Reading

Stay safe out there, and keep those parsers strict! What other subtle parsing bugs have you encountered that led to unexpected security issues? Share your thoughts below!

Read more