<?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>Tue, 06 Oct 2026 04:59:28 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-324123</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-324123</link>
      <description>EUVD-2026-324123</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-324123</guid>
    </item>
    <item>
      <title>fkie_cve-2026-49753</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-49753</link>
      <description>&lt;p&gt;Inconsistent Interpretation of HTTP Requests (&amp;#39;HTTP Request/Response Smuggling&amp;#39;) vulnerability in elixir-mint Mint allows attacker-controlled HTTP/1 servers to desynchronise response framing on shared connections.&lt;/p&gt;
&lt;p&gt;Mint&amp;#39;s HTTP/1 Content-Length parser, Mint.HTTP1.Parse.content_length_header/1 in lib/mint/http1/parse.ex, parses the header value with Integer.parse/1, which accepts an optional + or - sign prefix. The length &amp;gt;= 0 guard rejects negatives, but inputs such as +0 or +123 are returned as valid lengths. RFC 7230 specifies Content-Length = 1*DIGIT, with no sign character permitted.&lt;/p&gt;
&lt;p&gt;A fronting proxy or load balancer that strictly enforces the grammar will reject or reframe a header like Content-Length: +0, while Mint silently treats it as zero. When Mint reuses the socket (keep-alive, pipelining, or any pooled connection shared across requesters), the parser disagreement is a response-smuggling primitive: the proxy delimits the body one way, Mint another, and bytes from one response get attributed to the next. Where the same Mint connection is shared across trust boundaries, an attacker-controlled upstream can leak bytes into a different consumer&amp;#39;s response stream.&lt;/p&gt;
&lt;p&gt;This issue affects mint: from 0.1.0 before 1.9.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Inconsistent Interpretation of HTTP Requests (&amp;#39;HTTP Request/Response Smuggling&amp;#39;) vulnerability in elixir-mint Mint allows attacker-controlled HTTP/1 servers to desynchronise response framing on shared connections.&lt;/p&gt;
&lt;p&gt;Mint&amp;#39;s HTTP/1 Content-Length parser, Mint.HTTP1.Parse.content_length_header/1 in lib/mint/http1/parse.ex, parses the header value with Integer.parse/1, which accepts an optional + or - sign prefix. The length &amp;gt;= 0 guard rejects negatives, but inputs such as +0 or +123 are returned as valid lengths. RFC 7230 specifies Content-Length = 1*DIGIT, with no sign character permitted.&lt;/p&gt;
&lt;p&gt;A fronting proxy or load balancer that strictly enforces the grammar will reject or reframe a header like Content-Length: +0, while Mint silently treats it as zero. When Mint reuses the socket (keep-alive, pipelining, or any pooled connection shared across requesters), the parser disagreement is a response-smuggling primitive: the proxy delimits the body one way, Mint another, and bytes from one response get attributed to the next. Where the same Mint connection is shared across trust boundaries, an attacker-controlled upstream can leak bytes into a different consumer&amp;#39;s response stream.&lt;/p&gt;
&lt;p&gt;This issue affects mint: from 0.1.0 before 1.9.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-49753</guid>
    </item>
    <item>
      <title>GHSA-mjqx-c6f6-7rc2 — mint: Content-Length header accepts non-RFC "+" sign prefix</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-mjqx-c6f6-7rc2</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Hex: mint&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;Mint&amp;#39;s HTTP/1 client accepts `Content-Length` header values with a leading `+` sign (e.g. `+0`, `+123`), which RFC 7230 forbids (`Content-Length = 1*DIGIT`). On a connection shared with a strict fronting proxy or load balancer, this parser disagreement is a response-smuggling primitive: the proxy frames the body one way, Mint frames it another, and bytes meant for one response leak into the next consumer&amp;#39;s response stream.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;`&amp;#39;Elixir.Mint.HTTP1.Parse&amp;#39;:content_length_header/1` in `lib/mint/http1/parse.ex` parses the header value with `Integer.parse/1`. By design, `Integer.parse/1` accepts an optional `+` or `-` sign prefix. The `length &amp;gt;= 0` guard rules out negatives, but inputs such as `&amp;#34;+0&amp;#34;`, `&amp;#34;+123&amp;#34;`, or `&amp;#34;+1&amp;#34;` pass through and are returned as valid lengths.&lt;/p&gt;
&lt;p&gt;A strict proxy or load balancer rejects or reframes `Content-Length: +0\r\n`, while Mint silently treats it as `0`. When Mint reuses the socket (keep-alive, pipelining, or any pooled connection) and the connection is shared with a proxy that frames the same bytes differently, trailing bytes the proxy attributes to response N are attributed by Mint to response N+1. Across trust boundaries (shared pools, multi-tenant fronting) this enables response smuggling.&lt;/p&gt;
&lt;p&gt;### PoC&lt;/p&gt;
&lt;p&gt;1. Stand up a raw TCP server that returns `HTTP/1.1 200 OK\r\nContent-Length: +0\r\nConnection: keep-alive\r\n\r\n&amp;lt;smuggled bytes&amp;gt;`.
2. Connect a Mint HTTP/1 client to the server and issue a request.
3. Observe that Mint reports t…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Hex: mint&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;Mint&amp;#39;s HTTP/1 client accepts `Content-Length` header values with a leading `+` sign (e.g. `+0`, `+123`), which RFC 7230 forbids (`Content-Length = 1*DIGIT`). On a connection shared with a strict fronting proxy or load balancer, this parser disagreement is a response-smuggling primitive: the proxy frames the body one way, Mint frames it another, and bytes meant for one response leak into the next consumer&amp;#39;s response stream.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;`&amp;#39;Elixir.Mint.HTTP1.Parse&amp;#39;:content_length_header/1` in `lib/mint/http1/parse.ex` parses the header value with `Integer.parse/1`. By design, `Integer.parse/1` accepts an optional `+` or `-` sign prefix. The `length &amp;gt;= 0` guard rules out negatives, but inputs such as `&amp;#34;+0&amp;#34;`, `&amp;#34;+123&amp;#34;`, or `&amp;#34;+1&amp;#34;` pass through and are returned as valid lengths.&lt;/p&gt;
&lt;p&gt;A strict proxy or load balancer rejects or reframes `Content-Length: +0\r\n`, while Mint silently treats it as `0`. When Mint reuses the socket (keep-alive, pipelining, or any pooled connection) and the connection is shared with a proxy that frames the same bytes differently, trailing bytes the proxy attributes to response N are attributed by Mint to response N+1. Across trust boundaries (shared pools, multi-tenant fronting) this enables response smuggling.&lt;/p&gt;
&lt;p&gt;### PoC&lt;/p&gt;
&lt;p&gt;1. Stand up a raw TCP server that returns `HTTP/1.1 200 OK\r\nContent-Length: +0\r\nConnection: keep-alive\r\n\r\n&amp;lt;smuggled bytes&amp;gt;`.
2. Connect a Mint HTTP/1 client to the server and issue a request.
3. Observe that Mint reports t…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-mjqx-c6f6-7rc2</guid>
    </item>
  </channel>
</rss>
