Affected: Homebrew: aider
### 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…
Withdrawn by the publisher.
Affected: CleanStart: airflow-2
Multiple security vulnerabilities affect the airflow-2 package. These issues are resolved in later releases. See references for individual vulnerability details.
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.
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…
Affected: openEuler:24.03-LTS-SP1: python-h11
h11 is suitable for implementing both servers and clients, and has a pleasantly symmetric API: the events you send as a client are exactly the ones that you receive as a server and vice-versa. Security Fix(es):
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.(CVE-2025-43859)
python311-h11-0.16.0-1.1 on GA media
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: loc…
h11: h11 accepts some malformed Chunked-Encoding bodies
Security update for python-h11, python-httpcore
Affected: Ubuntu:24.04:LTS: python-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.
Ein entfernter, anonymer Angreifer kann eine Schwachstelle in Red Hat OpenStack ausnutzen, um Sicherheitsvorkehrungen zu umgehen.