<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Sun, 04 Oct 2026 10:21:39 +0000</lastBuildDate>
    <item>
      <title>CVE-2021-32714 — Integer Overflow in Chunked Transfer-Encoding</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2021-32714</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; hyperium hyper&lt;/p&gt;
&lt;p&gt;hyper is an HTTP library for Rust. In versions prior to 0.14.10, hyper&amp;#39;s HTTP server and client code had a flaw that could trigger an integer overflow when decoding chunk sizes that are too big. This allows possible data loss, or if combined with an upstream HTTP proxy that allows chunk sizes larger than hyper does, can result in &amp;#34;request smuggling&amp;#34; or &amp;#34;desync attacks.&amp;#34; The vulnerability is patched in version 0.14.10. Two possible workarounds exist. One may reject requests manually that contain a `Transfer-Encoding` header or ensure any upstream proxy rejects `Transfer-Encoding` chunk sizes greater than what fits in 64-bit unsigned integers.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; hyperium hyper&lt;/p&gt;
&lt;p&gt;hyper is an HTTP library for Rust. In versions prior to 0.14.10, hyper&amp;#39;s HTTP server and client code had a flaw that could trigger an integer overflow when decoding chunk sizes that are too big. This allows possible data loss, or if combined with an upstream HTTP proxy that allows chunk sizes larger than hyper does, can result in &amp;#34;request smuggling&amp;#34; or &amp;#34;desync attacks.&amp;#34; The vulnerability is patched in version 0.14.10. Two possible workarounds exist. One may reject requests manually that contain a `Transfer-Encoding` header or ensure any upstream proxy rejects `Transfer-Encoding` chunk sizes greater than what fits in 64-bit unsigned integers.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2021-32714</guid>
    </item>
    <item>
      <title>GHSA-5h46-h7hh-c6x9 — Integer Overflow in Chunked Transfer-Encoding</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-5h46-h7hh-c6x9</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; crates.io: hyper&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;hyper&amp;#39;s HTTP server and client code had a flaw that could trigger an integer overflow when decoding chunk sizes that are too big. This allows possible data loss, or if combined with an upstream HTTP proxy that allows chunk sizes larger than hyper does, can result in &amp;#34;request smuggling&amp;#34; or &amp;#34;desync attacks&amp;#34;.&lt;/p&gt;
&lt;p&gt;### Vulnerability&lt;/p&gt;
&lt;p&gt;Example:&lt;/p&gt;
&lt;p&gt;```
GET / HTTP/1.1
Host: example.com
Transfer-Encoding: chunked&lt;/p&gt;
&lt;p&gt;f0000000000000003
abc
0&lt;/p&gt;
&lt;p&gt;```&lt;/p&gt;
&lt;p&gt;hyper only reads the rightmost 64-bit integer as the chunk size. So it reads `f0000000000000003` as `3`. A loss of data can occur since hyper would then read only 3 bytes of the body. Additionally, an HTTP request smuggling vulnerability would occur if using a proxy which instead has prefix truncation in the chunk size, or that understands larger than 64-bit chunk sizes.&lt;/p&gt;
&lt;p&gt;Read more about desync attacks: https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;To determine if vulnerable to _data loss_, these things must be true:&lt;/p&gt;
&lt;p&gt;- **Using HTTP/1.1.** Since HTTP/2 does not use chunked encoding, it is not vulnerable.
- **Using hyper as a server or client.** The body would be improperly truncated in either case.
- **Users send requests or responses with chunk sizes greater than 18 exabytes**.&lt;/p&gt;
&lt;p&gt;To determine if vulnerable to _desync attacks_, these things must be true:&lt;/p&gt;
&lt;p&gt;- **Using an upstream proxy that allows chunks sizes larger than 64-bit.** If the proxy rejects chunk sizes that are too large, that request…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; crates.io: hyper&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;hyper&amp;#39;s HTTP server and client code had a flaw that could trigger an integer overflow when decoding chunk sizes that are too big. This allows possible data loss, or if combined with an upstream HTTP proxy that allows chunk sizes larger than hyper does, can result in &amp;#34;request smuggling&amp;#34; or &amp;#34;desync attacks&amp;#34;.&lt;/p&gt;
&lt;p&gt;### Vulnerability&lt;/p&gt;
&lt;p&gt;Example:&lt;/p&gt;
&lt;p&gt;```
GET / HTTP/1.1
Host: example.com
Transfer-Encoding: chunked&lt;/p&gt;
&lt;p&gt;f0000000000000003
abc
0&lt;/p&gt;
&lt;p&gt;```&lt;/p&gt;
&lt;p&gt;hyper only reads the rightmost 64-bit integer as the chunk size. So it reads `f0000000000000003` as `3`. A loss of data can occur since hyper would then read only 3 bytes of the body. Additionally, an HTTP request smuggling vulnerability would occur if using a proxy which instead has prefix truncation in the chunk size, or that understands larger than 64-bit chunk sizes.&lt;/p&gt;
&lt;p&gt;Read more about desync attacks: https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;To determine if vulnerable to _data loss_, these things must be true:&lt;/p&gt;
&lt;p&gt;- **Using HTTP/1.1.** Since HTTP/2 does not use chunked encoding, it is not vulnerable.
- **Using hyper as a server or client.** The body would be improperly truncated in either case.
- **Users send requests or responses with chunk sizes greater than 18 exabytes**.&lt;/p&gt;
&lt;p&gt;To determine if vulnerable to _desync attacks_, these things must be true:&lt;/p&gt;
&lt;p&gt;- **Using an upstream proxy that allows chunks sizes larger than 64-bit.** If the proxy rejects chunk sizes that are too large, that request…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-5h46-h7hh-c6x9</guid>
    </item>
  </channel>
</rss>
