Most recent entries from all

CVE-2025-43859 — h11 accepts some malformed Chunked-Encoding bodies

Affected: python-hyper h11

h11 is a Python implementation of HTTP/1.1. Prior to version 0.16.0, a leniency in h11's parsing of line terminators in chunked-coding message bodies can lead to request smuggling vulnerabilities under certain conditions. This issue has been patched in version 0.16.0. Since exploitation requires the combination of buggy h11 with a buggy (reverse) proxy, fixing either component is sufficient to mitigate this issue.

GHSA-vqfr-h8mv-ghfj — h11 accepts some malformed Chunked-Encoding bodies

Affected: PyPI: h11

### Impact

A leniency in h11's parsing of line terminators in chunked-coding message bodies can lead to request smuggling vulnerabilities under certain conditions.

### Details

HTTP/1.1 Chunked-Encoding bodies are formatted as a sequence of "chunks", each of which consists of:

- chunk length - `\r\n` - `length` bytes of content - `\r\n`

In versions of h11 up to 0.14.0, h11 instead parsed them as:

- chunk length - `\r\n` - `length` bytes of content - any two bytes

i.e. it did not validate that the trailing `\r\n` bytes were correct, and if you put 2 bytes of garbage there it would be accepted, instead of correctly rejecting the body as malformed.

By itself this is harmless. However, suppose you have a proxy or reverse-proxy that tries to analyze HTTP requests, and your proxy has a _different_ bug in parsing Chunked-Encoding, acting as if the format is:

- chunk length - `\r\n` - `length` bytes of content - more bytes of content, as many as it takes until you find a `\r\n`

For example, [pound](https://github.com/graygnuorg/pound/pull/43) had this bug -- it can happen if an implementer uses a generic "read until end of line" helper to consumes the trailing `\r\n`.

In this case, h11 and your proxy may both accept the same stream of bytes, but interpret them differently. For example, consider the following HTTP request(s) (assume all line breaks are `\r\n`):

``` GET /one HTTP/1.1 Host: localhost Transfer-Encoding: chunked

5 AAAAAXX2 45 0

GET /two HTTP/1.1 Host: localh…

PYSEC-2026-348 — h11 accepts some malformed Chunked-Encoding bodies

Affected: PyPI: h11

### Impact

A leniency in h11's parsing of line terminators in chunked-coding message bodies can lead to request smuggling vulnerabilities under certain conditions. ### Details

HTTP/1.1 Chunked-Encoding bodies are formatted as a sequence of "chunks", each of which consists of:

- chunk length - `\r\n` - `length` bytes of content - `\r\n`

In versions of h11 up to 0.14.0, h11 instead parsed them as:

- chunk length - `\r\n` - `length` bytes of content - any two bytes i.e. it did not validate that the trailing `\r\n` bytes were correct, and if you put 2 bytes of garbage there it would be accepted, instead of correctly rejecting the body as malformed.

- chunk length - `\r\n` - `length` bytes of content - more bytes of content, as many as it takes until you find a `\r\n`

For example, [pound](https://github.com/graygnuorg/pound/pull/43) had this bug -- it can happen if an implementer uses a generic "read until end of line" helper to consumes the trailing `\r\n`.

In this case, h11 and your proxy may both accept the same stream of bytes, but interpret them differently. For example, consider the following HTTP request(s) (assume all line breaks are `\r\n`):

``` GET /one HTTP/1.1 Host: localhost Transfer-Encoding: chunked 5 AAAAAXX2 45 0

GET /two HTTP/1.1 Host: loc…