<?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>Tue, 29 Sep 2026 07:06:04 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-65624 — Cowboy HTTP/1.1 max_headers Bypass via Duplicate Header Names Enables Memory Exhaustion</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-65624</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; ninenines cowboy&lt;/p&gt;
&lt;p&gt;Allocation of Resources Without Limits or Throttling vulnerability in ninenines cowboy allows an unauthenticated remote attacker to exhaust connection process memory over HTTP/1.1.&lt;/p&gt;
&lt;p&gt;The HTTP/1.1 handler in cowboy_http enforces the max_headers limit by counting the number of distinct header names in a map (maps:size(Headers)). When a request contains multiple header lines with the same name, the values are concatenated into a single ever-growing binary stored under that one map key (&amp;#34;, &amp;#34; for regular headers, &amp;#34;; &amp;#34; for cookies), so the map size stays at one and the max_headers cap (default 100) is never reached. Because no accumulator bounds the total number of header lines or the total byte size of the header block (only per-line max_header_name_length and max_header_value_length apply), an unauthenticated client can send an arbitrary number of header lines with the same name and grow the connection process&amp;#39;s binary memory to arbitrary size within the request window.&lt;/p&gt;
&lt;p&gt;The impact per connection is bounded by request_timeout (default 5 seconds, not reset by header data), and by max_heap_size when set (the offending connection process is killed once its heap grows past the limit). When max_heap_size is left at the default (unset), sustained abuse can drive the Erlang VM into out-of-memory conditions.&lt;/p&gt;
&lt;p&gt;This issue affects cowboy from 2.0.0-pre.4 before 2.18.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; ninenines cowboy&lt;/p&gt;
&lt;p&gt;Allocation of Resources Without Limits or Throttling vulnerability in ninenines cowboy allows an unauthenticated remote attacker to exhaust connection process memory over HTTP/1.1.&lt;/p&gt;
&lt;p&gt;The HTTP/1.1 handler in cowboy_http enforces the max_headers limit by counting the number of distinct header names in a map (maps:size(Headers)). When a request contains multiple header lines with the same name, the values are concatenated into a single ever-growing binary stored under that one map key (&amp;#34;, &amp;#34; for regular headers, &amp;#34;; &amp;#34; for cookies), so the map size stays at one and the max_headers cap (default 100) is never reached. Because no accumulator bounds the total number of header lines or the total byte size of the header block (only per-line max_header_name_length and max_header_value_length apply), an unauthenticated client can send an arbitrary number of header lines with the same name and grow the connection process&amp;#39;s binary memory to arbitrary size within the request window.&lt;/p&gt;
&lt;p&gt;The impact per connection is bounded by request_timeout (default 5 seconds, not reset by header data), and by max_heap_size when set (the offending connection process is killed once its heap grows past the limit). When max_heap_size is left at the default (unset), sustained abuse can drive the Erlang VM into out-of-memory conditions.&lt;/p&gt;
&lt;p&gt;This issue affects cowboy from 2.0.0-pre.4 before 2.18.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-65624</guid>
    </item>
  </channel>
</rss>
