<?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://vulnerability.circl.lu</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>Mon, 28 Sep 2026 23:34:16 +0000</lastBuildDate>
    <item>
      <title>BREW-mailcatcher-CVE-2026-34831 — Rack has Content-Length mismatch in Rack::Files error responses</title>
      <link>https://vulnerability.circl.lu/vuln/brew-mailcatcher-cve-2026-34831</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Homebrew: mailcatcher&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;`Rack::Files#fail` sets the `Content-Length` response header using `String#size` instead of `String#bytesize`. When the response body contains multibyte UTF-8 characters, the declared `Content-Length` is smaller than the number of bytes actually sent on the wire.&lt;/p&gt;
&lt;p&gt;Because `Rack::Files` reflects the requested path in 404 responses, an attacker can trigger this mismatch by requesting a non-existent path containing percent-encoded UTF-8 characters.&lt;/p&gt;
&lt;p&gt;This results in incorrect HTTP response framing and may cause response desynchronization in deployments that rely on the incorrect `Content-Length` value.&lt;/p&gt;
&lt;p&gt;## Details&lt;/p&gt;
&lt;p&gt;`Rack::Files#fail` constructs error responses using logic equivalent to:&lt;/p&gt;
&lt;p&gt;```ruby
def fail(status, body, headers = {})
  body += &amp;#34;\n&amp;#34;
  [
    status,
    {
      &amp;#34;content-type&amp;#34; =&amp;gt; &amp;#34;text/plain&amp;#34;,
      &amp;#34;content-length&amp;#34; =&amp;gt; body.size.to_s,
      &amp;#34;x-cascade&amp;#34; =&amp;gt; &amp;#34;pass&amp;#34;
    }.merge!(headers),
    [body]
  ]
end
```&lt;/p&gt;
&lt;p&gt;Here, `body.size` returns the number of characters, not the number of bytes. For multibyte UTF-8 strings, this produces an incorrect `Content-Length` value.&lt;/p&gt;
&lt;p&gt;`Rack::Files` includes the decoded request path in 404 responses. A request containing percent-encoded UTF-8 path components therefore causes the response body to contain multibyte characters, while the `Content-Length` header still reflects character count rather than byte count.&lt;/p&gt;
&lt;p&gt;As a result, the server can send more bytes than declared in the response headers.&lt;/p&gt;
&lt;p&gt;This violates HTTP message frami…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Homebrew: mailcatcher&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;`Rack::Files#fail` sets the `Content-Length` response header using `String#size` instead of `String#bytesize`. When the response body contains multibyte UTF-8 characters, the declared `Content-Length` is smaller than the number of bytes actually sent on the wire.&lt;/p&gt;
&lt;p&gt;Because `Rack::Files` reflects the requested path in 404 responses, an attacker can trigger this mismatch by requesting a non-existent path containing percent-encoded UTF-8 characters.&lt;/p&gt;
&lt;p&gt;This results in incorrect HTTP response framing and may cause response desynchronization in deployments that rely on the incorrect `Content-Length` value.&lt;/p&gt;
&lt;p&gt;## Details&lt;/p&gt;
&lt;p&gt;`Rack::Files#fail` constructs error responses using logic equivalent to:&lt;/p&gt;
&lt;p&gt;```ruby
def fail(status, body, headers = {})
  body += &amp;#34;\n&amp;#34;
  [
    status,
    {
      &amp;#34;content-type&amp;#34; =&amp;gt; &amp;#34;text/plain&amp;#34;,
      &amp;#34;content-length&amp;#34; =&amp;gt; body.size.to_s,
      &amp;#34;x-cascade&amp;#34; =&amp;gt; &amp;#34;pass&amp;#34;
    }.merge!(headers),
    [body]
  ]
end
```&lt;/p&gt;
&lt;p&gt;Here, `body.size` returns the number of characters, not the number of bytes. For multibyte UTF-8 strings, this produces an incorrect `Content-Length` value.&lt;/p&gt;
&lt;p&gt;`Rack::Files` includes the decoded request path in 404 responses. A request containing percent-encoded UTF-8 path components therefore causes the response body to contain multibyte characters, while the `Content-Length` header still reflects character count rather than byte count.&lt;/p&gt;
&lt;p&gt;As a result, the server can send more bytes than declared in the response headers.&lt;/p&gt;
&lt;p&gt;This violates HTTP message frami…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/brew-mailcatcher-cve-2026-34831</guid>
    </item>
    <item>
      <title>CVE-2026-34831 — Rack: Content-Length mismatch in Rack::Files error responses</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-34831</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; rack&lt;/p&gt;
&lt;p&gt;Rack is a modular Ruby web server interface. Prior to versions 2.2.23, 3.1.21, and 3.2.6, Rack::Files#fail sets the Content-Length response header using String#size instead of String#bytesize. When the response body contains multibyte UTF-8 characters, the declared Content-Length is smaller than the number of bytes actually sent on the wire. Because Rack::Files reflects the requested path in 404 responses, an attacker can trigger this mismatch by requesting a non-existent path containing percent-encoded UTF-8 characters. This results in incorrect HTTP response framing and may cause response desynchronization in deployments that rely on the incorrect Content-Length value. This issue has been patched in versions 2.2.23, 3.1.21, and 3.2.6.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; rack&lt;/p&gt;
&lt;p&gt;Rack is a modular Ruby web server interface. Prior to versions 2.2.23, 3.1.21, and 3.2.6, Rack::Files#fail sets the Content-Length response header using String#size instead of String#bytesize. When the response body contains multibyte UTF-8 characters, the declared Content-Length is smaller than the number of bytes actually sent on the wire. Because Rack::Files reflects the requested path in 404 responses, an attacker can trigger this mismatch by requesting a non-existent path containing percent-encoded UTF-8 characters. This results in incorrect HTTP response framing and may cause response desynchronization in deployments that rely on the incorrect Content-Length value. This issue has been patched in versions 2.2.23, 3.1.21, and 3.2.6.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-34831</guid>
    </item>
  </channel>
</rss>
