https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 03:16:58 +0000 https://cve.radiocsirt.org/vuln/bdu:2025-06251 bdu:2025-06251 https://cve.radiocsirt.org/vuln/bdu:2025-06251 https://cve.radiocsirt.org/vuln/brew-aider-cve-2025-43859 <p><strong>Affected:</strong> Homebrew: aider</p> <p>### Impact</p> <p>A leniency in h11&#39;s parsing of line terminators in chunked-coding message bodies can lead to request smuggling vulnerabilities under certain conditions.</p> <p>### Details</p> <p>HTTP/1.1 Chunked-Encoding bodies are formatted as a sequence of &#34;chunks&#34;, each of which consists of:</p> <p>- chunk length - `\r\n` - `length` bytes of content - `\r\n`</p> <p>In versions of h11 up to 0.14.0, h11 instead parsed them as:</p> <p>- chunk length - `\r\n` - `length` bytes of content - any two bytes</p> <p>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.</p> <p>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:</p> <p>- chunk length - `\r\n` - `length` bytes of content - more bytes of content, as many as it takes until you find a `\r\n`</p> <p>For example, [pound](https://github.com/graygnuorg/pound/pull/43) had this bug -- it can happen if an implementer uses a generic &#34;read until end of line&#34; helper to consumes the trailing `\r\n`.</p> <p>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`):</p> <p>``` GET /one HTTP/1.1 Host: localhost Transfer-Encoding: chunked</p> <p>5 AAAAAXX2 45 0</p> <p>GET /two HTTP/1.1 Host: localh…</p> <p><strong>Affected:</strong> Homebrew: aider</p> <p>### Impact</p> <p>A leniency in h11&#39;s parsing of line terminators in chunked-coding message bodies can lead to request smuggling vulnerabilities under certain conditions.</p> <p>### Details</p> <p>HTTP/1.1 Chunked-Encoding bodies are formatted as a sequence of &#34;chunks&#34;, each of which consists of:</p> <p>- chunk length - `\r\n` - `length` bytes of content - `\r\n`</p> <p>In versions of h11 up to 0.14.0, h11 instead parsed them as:</p> <p>- chunk length - `\r\n` - `length` bytes of content - any two bytes</p> <p>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.</p> <p>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:</p> <p>- chunk length - `\r\n` - `length` bytes of content - more bytes of content, as many as it takes until you find a `\r\n`</p> <p>For example, [pound](https://github.com/graygnuorg/pound/pull/43) had this bug -- it can happen if an implementer uses a generic &#34;read until end of line&#34; helper to consumes the trailing `\r\n`.</p> <p>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`):</p> <p>``` GET /one HTTP/1.1 Host: localhost Transfer-Encoding: chunked</p> <p>5 AAAAAXX2 45 0</p> <p>GET /two HTTP/1.1 Host: localh…</p> https://cve.radiocsirt.org/vuln/brew-aider-cve-2025-43859 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0512 certfr-2025-avi-0512 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0512 https://cve.radiocsirt.org/vuln/cleanstart-2026-an24336 <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Affected:</strong> CleanStart: airflow-2</p> <p>Multiple security vulnerabilities affect the airflow-2 package. These issues are resolved in later releases. See references for individual vulnerability details.</p> <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Affected:</strong> CleanStart: airflow-2</p> <p>Multiple security vulnerabilities affect the airflow-2 package. These issues are resolved in later releases. See references for individual vulnerability details.</p> https://cve.radiocsirt.org/vuln/cleanstart-2026-an24336 https://cve.radiocsirt.org/vuln/euvd-2026-235053 EUVD-2026-235053 https://cve.radiocsirt.org/vuln/euvd-2026-235053 https://cve.radiocsirt.org/vuln/fkie_cve-2025-43859 <p>h11 is a Python implementation of HTTP/1.1. Prior to version 0.16.0, a leniency in h11&#39;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.</p> <p>h11 is a Python implementation of HTTP/1.1. Prior to version 0.16.0, a leniency in h11&#39;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.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2025-43859 https://cve.radiocsirt.org/vuln/ghsa-vqfr-h8mv-ghfj <p><strong>Affected:</strong> PyPI: h11</p> <p>### Impact</p> <p>A leniency in h11&#39;s parsing of line terminators in chunked-coding message bodies can lead to request smuggling vulnerabilities under certain conditions.</p> <p>### Details</p> <p>HTTP/1.1 Chunked-Encoding bodies are formatted as a sequence of &#34;chunks&#34;, each of which consists of:</p> <p>- chunk length - `\r\n` - `length` bytes of content - `\r\n`</p> <p>In versions of h11 up to 0.14.0, h11 instead parsed them as:</p> <p>- chunk length - `\r\n` - `length` bytes of content - any two bytes</p> <p>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.</p> <p>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:</p> <p>- chunk length - `\r\n` - `length` bytes of content - more bytes of content, as many as it takes until you find a `\r\n`</p> <p>For example, [pound](https://github.com/graygnuorg/pound/pull/43) had this bug -- it can happen if an implementer uses a generic &#34;read until end of line&#34; helper to consumes the trailing `\r\n`.</p> <p>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`):</p> <p>``` GET /one HTTP/1.1 Host: localhost Transfer-Encoding: chunked</p> <p>5 AAAAAXX2 45 0</p> <p>GET /two HTTP/1.1 Host: localh…</p> <p><strong>Affected:</strong> PyPI: h11</p> <p>### Impact</p> <p>A leniency in h11&#39;s parsing of line terminators in chunked-coding message bodies can lead to request smuggling vulnerabilities under certain conditions.</p> <p>### Details</p> <p>HTTP/1.1 Chunked-Encoding bodies are formatted as a sequence of &#34;chunks&#34;, each of which consists of:</p> <p>- chunk length - `\r\n` - `length` bytes of content - `\r\n`</p> <p>In versions of h11 up to 0.14.0, h11 instead parsed them as:</p> <p>- chunk length - `\r\n` - `length` bytes of content - any two bytes</p> <p>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.</p> <p>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:</p> <p>- chunk length - `\r\n` - `length` bytes of content - more bytes of content, as many as it takes until you find a `\r\n`</p> <p>For example, [pound](https://github.com/graygnuorg/pound/pull/43) had this bug -- it can happen if an implementer uses a generic &#34;read until end of line&#34; helper to consumes the trailing `\r\n`.</p> <p>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`):</p> <p>``` GET /one HTTP/1.1 Host: localhost Transfer-Encoding: chunked</p> <p>5 AAAAAXX2 45 0</p> <p>GET /two HTTP/1.1 Host: localh…</p> https://cve.radiocsirt.org/vuln/ghsa-vqfr-h8mv-ghfj https://cve.radiocsirt.org/vuln/oesa-2025-1496 <p><strong>Affected:</strong> openEuler:24.03-LTS-SP1: python-h11</p> <p>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):</p> <p>h11 is a Python implementation of HTTP/1.1. Prior to version 0.16.0, a leniency in h11&amp;apos;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)</p> <p><strong>Affected:</strong> openEuler:24.03-LTS-SP1: python-h11</p> <p>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):</p> <p>h11 is a Python implementation of HTTP/1.1. Prior to version 0.16.0, a leniency in h11&amp;apos;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)</p> https://cve.radiocsirt.org/vuln/oesa-2025-1496 https://cve.radiocsirt.org/vuln/opensuse-su-2025:15032-1 <p>python311-h11-0.16.0-1.1 on GA media</p> <p>python311-h11-0.16.0-1.1 on GA media</p> https://cve.radiocsirt.org/vuln/opensuse-su-2025:15032-1 https://cve.radiocsirt.org/vuln/pysec-2026-348 <p><strong>Affected:</strong> PyPI: h11</p> <p>### Impact</p> <p>A leniency in h11&#39;s parsing of line terminators in chunked-coding message bodies can lead to request smuggling vulnerabilities under certain conditions. ### Details</p> <p>HTTP/1.1 Chunked-Encoding bodies are formatted as a sequence of &#34;chunks&#34;, each of which consists of:</p> <p>- chunk length - `\r\n` - `length` bytes of content - `\r\n`</p> <p>In versions of h11 up to 0.14.0, h11 instead parsed them as:</p> <p>- 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.</p> <p>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:</p> <p>- chunk length - `\r\n` - `length` bytes of content - more bytes of content, as many as it takes until you find a `\r\n`</p> <p>For example, [pound](https://github.com/graygnuorg/pound/pull/43) had this bug -- it can happen if an implementer uses a generic &#34;read until end of line&#34; helper to consumes the trailing `\r\n`.</p> <p>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`):</p> <p>``` GET /one HTTP/1.1 Host: localhost Transfer-Encoding: chunked 5 AAAAAXX2 45 0</p> <p>GET /two HTTP/1.1 Host: loc…</p> <p><strong>Affected:</strong> PyPI: h11</p> <p>### Impact</p> <p>A leniency in h11&#39;s parsing of line terminators in chunked-coding message bodies can lead to request smuggling vulnerabilities under certain conditions. ### Details</p> <p>HTTP/1.1 Chunked-Encoding bodies are formatted as a sequence of &#34;chunks&#34;, each of which consists of:</p> <p>- chunk length - `\r\n` - `length` bytes of content - `\r\n`</p> <p>In versions of h11 up to 0.14.0, h11 instead parsed them as:</p> <p>- 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.</p> <p>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:</p> <p>- chunk length - `\r\n` - `length` bytes of content - more bytes of content, as many as it takes until you find a `\r\n`</p> <p>For example, [pound](https://github.com/graygnuorg/pound/pull/43) had this bug -- it can happen if an implementer uses a generic &#34;read until end of line&#34; helper to consumes the trailing `\r\n`.</p> <p>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`):</p> <p>``` GET /one HTTP/1.1 Host: localhost Transfer-Encoding: chunked 5 AAAAAXX2 45 0</p> <p>GET /two HTTP/1.1 Host: loc…</p> https://cve.radiocsirt.org/vuln/pysec-2026-348 https://cve.radiocsirt.org/vuln/rhsa-2025:7535 <p>h11: h11 accepts some malformed Chunked-Encoding bodies</p> <p>h11: h11 accepts some malformed Chunked-Encoding bodies</p> https://cve.radiocsirt.org/vuln/rhsa-2025:7535 https://cve.radiocsirt.org/vuln/suse-su-2025:20330-1 <p>Security update for python-h11, python-httpcore</p> <p>Security update for python-h11, python-httpcore</p> https://cve.radiocsirt.org/vuln/suse-su-2025:20330-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-43859 <p><strong>Affected:</strong> Ubuntu:24.04:LTS: python-h11</p> <p>h11 is a Python implementation of HTTP/1.1. Prior to version 0.16.0, a leniency in h11&#39;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.</p> <p><strong>Affected:</strong> Ubuntu:24.04:LTS: python-h11</p> <p>h11 is a Python implementation of HTTP/1.1. Prior to version 0.16.0, a leniency in h11&#39;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.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-43859 https://cve.radiocsirt.org/vuln/wid-sec-w-2025-1022 <p>Ein entfernter, anonymer Angreifer kann eine Schwachstelle in Red Hat OpenStack ausnutzen, um Sicherheitsvorkehrungen zu umgehen.</p> <p>Ein entfernter, anonymer Angreifer kann eine Schwachstelle in Red Hat OpenStack ausnutzen, um Sicherheitsvorkehrungen zu umgehen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2025-1022