{"dataType": "CVE_RECORD", "dataVersion": "5.2", "cveMetadata": {"cveId": "CVE-2026-113431", "assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db", "state": "PUBLISHED", "assignerShortName": "EEF", "dateReserved": "2026-10-30T12:30:02.006Z", "datePublished": "2026-11-06T10:28:15.837Z", "dateUpdated": "2026-11-06T10:28:15.837Z"}, "containers": {"cna": {"affected": [{"collectionURL": "https://repo.hex.pm", "cpes": ["cpe:2.3:a:ninenines:cowlib:*:*:*:*:*:*:*:*"], "defaultStatus": "unaffected", "modules": ["cow_http2_machine", "cow_hpack"], "packageName": "cowlib", "packageURL": "pkg:hex/cowlib", "product": "cowlib", "programFiles": ["src/cow_http2_machine.erl", "src/cow_hpack.erl"], "programRoutines": [{"name": "cow_http2_machine:headers_decode/4"}, {"name": "cow_http2_machine:frame/2"}, {"name": "cow_hpack:decode/3"}, {"name": "cow_hpack:decode/2"}], "repo": "https://github.com/ninenines/cowlib", "vendor": "ninenines", "versions": [{"lessThan": "*", "status": "affected", "version": "2.7.0", "versionType": "semver"}]}, {"collectionURL": "https://github.com", "cpes": ["cpe:2.3:a:ninenines:cowlib:*:*:*:*:*:*:*:*"], "defaultStatus": "unaffected", "modules": ["cow_http2_machine", "cow_hpack"], "packageName": "ninenines/cowlib", "packageURL": "pkg:github/ninenines/cowlib", "product": "cowlib", "programFiles": ["src/cow_http2_machine.erl", "src/cow_hpack.erl"], "programRoutines": [{"name": "cow_http2_machine:headers_decode/4"}, {"name": "cow_http2_machine:frame/2"}, {"name": "cow_hpack:decode/3"}, {"name": "cow_hpack:decode/2"}], "repo": "https://github.com/ninenines/cowlib", "vendor": "ninenines", "versions": [{"lessThan": "a3b15e29b3067644bfd580246c87f7af7a90b3b8", "status": "affected", "version": "b461b119e78e4e09bb28b186b09da7ed4a86a0dd", "versionType": "git"}]}], "cpeApplicability": [{"nodes": [{"cpeMatch": [{"criteria": "cpe:2.3:a:ninenines:cowlib:*:*:*:*:*:*:*:*", "versionStartIncluding": "2.7.0", "vulnerable": true}], "negate": false, "operator": "OR"}], "operator": "AND"}], "credits": [{"lang": "en", "type": "finder", "value": "Andrew Moore"}, {"lang": "en", "type": "reporter", "value": "Andrew Moore"}, {"lang": "en", "type": "remediation developer", "value": "Lo\u00efc Hoguin"}, {"lang": "en", "type": "coordinator", "value": "Jonatan M\u00e4nnchen / EEF"}], "dateAssigned": "2026-10-30T12:35:17.000Z", "descriptions": [{"lang": "en", "supportingMedia": [{"base64": false, "type": "text/html", "value": "<p>Allocation of Resources Without Limits or Throttling vulnerability in ninenines cowlib allows an unauthenticated remote peer to exhaust the memory of an HTTP/2 endpoint via HPACK-indexed header fields.</p>\n<p><code>cow_http2_machine:headers_decode/4</code> in <code>src/cow_http2_machine.erl</code> decodes every HEADERS block with <code>cow_hpack:decode/3</code>. It bounds the compressed block size and the number of fields, but not the size of the decoded header list that RFC 9113 section 6.5.2 places under <code>SETTINGS_MAX_HEADER_LIST_SIZE</code>. A peer stores one header value of up to the dynamic table size (4096 bytes by default) and then references it with one-byte indexed fields, so about 100 bytes on the wire decode to a header list of about 390 KB. A consumer that copies the decoded values, as Cowboy does when <code>cowboy_http2:headers_to_map/2</code> joins repeated <code>cookie</code> fields into one binary, allocates that amount for every stream. The total across streams and connections is not bounded.</p>\n<p>This issue affects cowlib: from 2.7.0 onward.</p>"}, {"base64": false, "type": "text/markdown", "value": "Allocation of Resources Without Limits or Throttling vulnerability in ninenines cowlib allows an unauthenticated remote peer to exhaust the memory of an HTTP/2 endpoint via HPACK-indexed header fields.\n\n`cow_http2_machine:headers_decode/4` in `src/cow_http2_machine.erl` decodes every HEADERS block with `cow_hpack:decode/3`. It bounds the compressed block size and the number of fields, but not the size of the decoded header list that RFC 9113 section 6.5.2 places under `SETTINGS_MAX_HEADER_LIST_SIZE`. A peer stores one header value of up to the dynamic table size (4096 bytes by default) and then references it with one-byte indexed fields, so about 100 bytes on the wire decode to a header list of about 390 KB. A consumer that copies the decoded values, as Cowboy does when `cowboy_http2:headers_to_map/2` joins repeated `cookie` fields into one binary, allocates that amount for every stream. The total across streams and connections is not bounded.\n\nThis issue affects cowlib: from 2.7.0 onward."}], "value": "Allocation of Resources Without Limits or Throttling vulnerability in ninenines cowlib allows an unauthenticated remote peer to exhaust the memory of an HTTP/2 endpoint via HPACK-indexed header fields.\n\ncow_http2_machine:headers_decode/4 in src/cow_http2_machine.erl decodes every HEADERS block with cow_hpack:decode/3. It bounds the compressed block size and the number of fields, but not the size of the decoded header list that RFC 9113 section 6.5.2 places under SETTINGS_MAX_HEADER_LIST_SIZE. A peer stores one header value of up to the dynamic table size (4096 bytes by default) and then references it with one-byte indexed fields, so about 100 bytes on the wire decode to a header list of about 390 KB. A consumer that copies the decoded values, as Cowboy does when cowboy_http2:headers_to_map/2 joins repeated cookie fields into one binary, allocates that amount for every stream. The total across streams and connections is not bounded.\n\nThis issue affects cowlib: from 2.7.0 onward."}], "impacts": [{"capecId": "CAPEC-491", "descriptions": [{"lang": "en", "supportingMedia": [{"base64": false, "type": "text/html", "value": "<p>A remote unauthenticated client makes an HTTP/2 server built on cowlib, such as a Cowboy listener, allocate roughly 2,400 times the bytes it sends. One connection reaches about 38 MB with default settings, and an attacker holding many connections can drive the Erlang VM out of memory.</p>"}, {"base64": false, "type": "text/markdown", "value": "A remote unauthenticated client makes an HTTP/2 server built on cowlib, such as a Cowboy listener, allocate roughly 2,400 times the bytes it sends. One connection reaches about 38 MB with default settings, and an attacker holding many connections can drive the Erlang VM out of memory."}], "value": "A remote unauthenticated client makes an HTTP/2 server built on cowlib, such as a Cowboy listener, allocate roughly 2,400 times the bytes it sends. One connection reaches about 38 MB with default settings, and an attacker holding many connections can drive the Erlang VM out of memory."}]}], "metrics": [{"cvssV4_0": {"Automatable": "NOT_DEFINED", "Recovery": "NOT_DEFINED", "Safety": "NOT_DEFINED", "attackComplexity": "LOW", "attackRequirements": "NONE", "attackVector": "NETWORK", "baseScore": 8.7, "baseSeverity": "HIGH", "privilegesRequired": "NONE", "providerUrgency": "NOT_DEFINED", "subAvailabilityImpact": "NONE", "subConfidentialityImpact": "NONE", "subIntegrityImpact": "NONE", "userInteraction": "NONE", "valueDensity": "NOT_DEFINED", "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N", "version": "4.0", "vulnAvailabilityImpact": "HIGH", "vulnConfidentialityImpact": "NONE", "vulnIntegrityImpact": "NONE", "vulnerabilityResponseEffort": "NOT_DEFINED"}, "format": "CVSS", "scenarios": [{"lang": "en", "value": "GENERAL"}]}], "problemTypes": [{"descriptions": [{"cweId": "CWE-770", "description": "CWE-770 Allocation of Resources Without Limits or Throttling", "lang": "en", "type": "CWE"}]}], "providerMetadata": {"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db", "shortName": "EEF", "dateUpdated": "2026-11-06T10:28:15.837Z"}, "references": [{"name": "EEF CNA record for CVE-2026-113431", "tags": ["related", "third-party-advisory"], "url": "https://cna.erlef.org/cves/CVE-2026-113431.html"}, {"name": "OSV record EEF-CVE-2026-113431", "tags": ["related"], "url": "https://osv.dev/vulnerability/EEF-CVE-2026-113431"}, {"name": "Introducing commit b461b11 in ninenines/cowlib", "tags": ["related"], "url": "https://github.com/ninenines/cowlib/commit/b461b119e78e4e09bb28b186b09da7ed4a86a0dd"}, {"name": "Fix commit a3b15e2 in ninenines/cowlib", "tags": ["patch"], "url": "https://github.com/ninenines/cowlib/commit/a3b15e29b3067644bfd580246c87f7af7a90b3b8"}], "source": {"discovery": "EXTERNAL"}, "title": "Unbounded decoded HTTP/2 header-list size in cowlib cow_http2_machine enables HPACK amplification memory exhaustion", "workarounds": [{"lang": "en", "supportingMedia": [{"base64": false, "type": "text/html", "value": "<p>Cowboy servers that do not need HTTP/2 can set <code>protocols =&gt; [http]</code> in the protocol options. The listener then answers the HTTP/2 preface with <code>501 Not Implemented</code> and the decoder is never reached.</p>\n<p>Lowering <code>max_headers</code> in the HTTP/2 protocol options shrinks the per-stream allocation in proportion, to about <code>max_headers</code> times the 4096-byte table entry. This reduces the amplification but does not remove it.</p>"}, {"base64": false, "type": "text/markdown", "value": "Cowboy servers that do not need HTTP/2 can set `protocols => [http]` in the protocol options. The listener then answers the HTTP/2 preface with `501 Not Implemented` and the decoder is never reached.\n\nLowering `max_headers` in the HTTP/2 protocol options shrinks the per-stream allocation in proportion, to about `max_headers` times the 4096-byte table entry. This reduces the amplification but does not remove it."}], "value": "Cowboy servers that do not need HTTP/2 can set protocols => [http] in the protocol options. The listener then answers the HTTP/2 preface with 501 Not Implemented and the decoder is never reached.\n\nLowering max_headers in the HTTP/2 protocol options shrinks the per-stream allocation in proportion, to about max_headers times the 4096-byte table entry. This reduces the amplification but does not remove it."}], "x_proofOfConcept": [{"lang": "en", "supportingMedia": [{"base64": false, "type": "text/html", "value": "<ol>\n<li>Start a Cowboy clear listener with default protocol options and a handler that takes a few seconds to reply, so streams stay open.</li>\n<li>Open one TCP connection, send the HTTP/2 client preface and an empty SETTINGS frame.</li>\n<li>On stream 1 send a HEADERS frame with <code>END_HEADERS</code> and <code>END_STREAM</code> whose block contains <code>:method</code>, <code>:scheme</code>, <code>:path</code> and <code>:authority</code>, then one literal <code>cookie</code> field with incremental indexing carrying a 4000-byte value, then 95 indexed fields <code>0xBE</code> referencing it.</li>\n<li>On streams 3 through 199 send the same frame with the four pseudo-headers followed by 96 indexed fields <code>0xBE</code>. Each block is 110 bytes.</li>\n<li>Watch <code>erlang:memory(binary)</code> on the server. It grows by about 38 MB for about 16 KB sent, and <code>cowboy_req:header(&lt;&lt;\"cookie\"&gt;&gt;, Req)</code> in each handler returns a 384,190-byte binary.</li>\n</ol>"}, {"base64": false, "type": "text/markdown", "value": "1. Start a Cowboy clear listener with default protocol options and a handler that takes a few seconds to reply, so streams stay open.\n2. Open one TCP connection, send the HTTP/2 client preface and an empty SETTINGS frame.\n3. On stream 1 send a HEADERS frame with `END_HEADERS` and `END_STREAM` whose block contains `:method`, `:scheme`, `:path` and `:authority`, then one literal `cookie` field with incremental indexing carrying a 4000-byte value, then 95 indexed fields `0xBE` referencing it.\n4. On streams 3 through 199 send the same frame with the four pseudo-headers followed by 96 indexed fields `0xBE`. Each block is 110 bytes.\n5. Watch `erlang:memory(binary)` on the server. It grows by about 38 MB for about 16 KB sent, and `cowboy_req:header(<<\"cookie\">>, Req)` in each handler returns a 384,190-byte binary."}], "value": "* Start a Cowboy clear listener with default protocol options and a handler that takes a few seconds to reply, so streams stay open.\n* Open one TCP connection, send the HTTP/2 client preface and an empty SETTINGS frame.\n* On stream 1 send a HEADERS frame with END_HEADERS and END_STREAM whose block contains :method, :scheme, :path and :authority, then one literal cookie field with incremental indexing carrying a 4000-byte value, then 95 indexed fields 0xBE referencing it.\n* On streams 3 through 199 send the same frame with the four pseudo-headers followed by 96 indexed fields 0xBE. Each block is 110 bytes.\n* Watch erlang:memory(binary) on the server. It grows by about 38 MB for about 16 KB sent, and cowboy_req:header(<<\"cookie\">>, Req) in each handler returns a 384,190-byte binary."}], "x_technicalAnalysis": [{"lang": "en", "supportingMedia": [{"base64": false, "type": "text/html", "value": "<p><strong>1. The decoder bounds everything but the decoded size.</strong> <code>cow_http2_machine:headers_decode/4</code> passes each complete header block to <code>cow_hpack:decode/3</code>. Two limits apply: <code>max_fragmented_header_block_size</code> (32768 bytes by default) on the compressed block, and <code>max_headers</code> (100 by default, added in cowlib 2.17.0) on the number of fields. <code>max_header_list_size</code> appears in the module's option list with a default of <code>infinity</code>, next to a <code>@todo</code> comment, and is neither advertised in SETTINGS nor enforced on the decoded list, which is what RFC 9113 section 6.5.2 defines it for.</p>\n<p><strong>2. One-byte fields expand to kilobytes.</strong> The dynamic table holds entries of up to <code>max_decode_table_size</code> (4096 bytes by default). The peer sends one literal field with incremental indexing carrying a 4000-byte value, which becomes table entry 62. Every later field is the single byte <code>0xBE</code>, an indexed representation of that entry. A 110-byte block that carries four pseudo-headers and 96 such references decodes to a 100-field list whose values total 384,000 bytes. Before 2.17.0 no field count applied, so a 32 KB block referenced the entry about 32,000 times.</p>\n<p><strong>3. The allocation is realised by the consumer.</strong> The list that <code>cow_hpack</code> returns is cheap, about 2 KB of heap, because every reference shares the one table binary. Cowboy's <code>cowboy_http2:headers_to_map/2</code> joins repeated fields into a single new binary (<code>\"; \"</code> for <code>cookie</code>, <code>\", \"</code> for other names), so each stream yields a 384,190-byte cookie value that lives in the request process for the life of the stream. Cowboy's HTTP/1.1 limits <code>max_header_value_length</code> and <code>max_headers</code> do not apply to HTTP/2. With the default <code>max_concurrent_streams</code> of 100 a connection holds about 38 MB, and only the Ranch connection limit bounds the total. Gun hands the decoded list to the owner process without copying the values, so the client side sees a small list per response and no amplification.</p>\n<p><strong>4. Measurement.</strong> On cowboy 2.20.0 with cowlib 2.21.0 on Erlang/OTP 29, one h2c connection on loopback sent 15,943 bytes of HEADERS for 100 streams. Binary memory grew by 38.4 MB and every handler received a 384,190-byte <code>cookie</code> header. A control with the same 100 streams and no indexed fields grew by 0.</p>"}, {"base64": false, "type": "text/markdown", "value": "**1. The decoder bounds everything but the decoded size.** `cow_http2_machine:headers_decode/4` passes each complete header block to `cow_hpack:decode/3`. Two limits apply: `max_fragmented_header_block_size` (32768 bytes by default) on the compressed block, and `max_headers` (100 by default, added in cowlib 2.17.0) on the number of fields. `max_header_list_size` appears in the module's option list with a default of `infinity`, next to a `@todo` comment, and is neither advertised in SETTINGS nor enforced on the decoded list, which is what RFC 9113 section 6.5.2 defines it for.\n\n**2. One-byte fields expand to kilobytes.** The dynamic table holds entries of up to `max_decode_table_size` (4096 bytes by default). The peer sends one literal field with incremental indexing carrying a 4000-byte value, which becomes table entry 62. Every later field is the single byte `0xBE`, an indexed representation of that entry. A 110-byte block that carries four pseudo-headers and 96 such references decodes to a 100-field list whose values total 384,000 bytes. Before 2.17.0 no field count applied, so a 32 KB block referenced the entry about 32,000 times.\n\n**3. The allocation is realised by the consumer.** The list that `cow_hpack` returns is cheap, about 2 KB of heap, because every reference shares the one table binary. Cowboy's `cowboy_http2:headers_to_map/2` joins repeated fields into a single new binary (`\"; \"` for `cookie`, `\", \"` for other names), so each stream yields a 384,190-byte cookie value that lives in the request process for the life of the stream. Cowboy's HTTP/1.1 limits `max_header_value_length` and `max_headers` do not apply to HTTP/2. With the default `max_concurrent_streams` of 100 a connection holds about 38 MB, and only the Ranch connection limit bounds the total. Gun hands the decoded list to the owner process without copying the values, so the client side sees a small list per response and no amplification.\n\n**4. Measurement.** On cowboy 2.20.0 with cowlib 2.21.0 on Erlang/OTP 29, one h2c connection on loopback sent 15,943 bytes of HEADERS for 100 streams. Binary memory grew by 38.4 MB and every handler received a 384,190-byte `cookie` header. A control with the same 100 streams and no indexed fields grew by 0."}], "value": "1. The decoder bounds everything but the decoded size. cow_http2_machine:headers_decode/4 passes each complete header block to cow_hpack:decode/3. Two limits apply: max_fragmented_header_block_size (32768 bytes by default) on the compressed block, and max_headers (100 by default, added in cowlib 2.17.0) on the number of fields. max_header_list_size appears in the module's option list with a default of infinity, next to a @todo comment, and is neither advertised in SETTINGS nor enforced on the decoded list, which is what RFC 9113 section 6.5.2 defines it for.\n\n2. One-byte fields expand to kilobytes. The dynamic table holds entries of up to max_decode_table_size (4096 bytes by default). The peer sends one literal field with incremental indexing carrying a 4000-byte value, which becomes table entry 62. Every later field is the single byte 0xBE, an indexed representation of that entry. A 110-byte block that carries four pseudo-headers and 96 such references decodes to a 100-field list whose values total 384,000 bytes. Before 2.17.0 no field count applied, so a 32 KB block referenced the entry about 32,000 times.\n\n3. The allocation is realised by the consumer. The list that cow_hpack returns is cheap, about 2 KB of heap, because every reference shares the one table binary. Cowboy's cowboy_http2:headers_to_map/2 joins repeated fields into a single new binary (\"; \" for cookie, \", \" for other names), so each stream yields a 384,190-byte cookie value that lives in the request process for the life of the stream. Cowboy's HTTP/1.1 limits max_header_value_length and max_headers do not apply to HTTP/2. With the default max_concurrent_streams of 100 a connection holds about 38 MB, and only the Ranch connection limit bounds the total. Gun hands the decoded list to the owner process without copying the values, so the client side sees a small list per response and no amplification.\n\n4. Measurement. On cowboy 2.20.0 with cowlib 2.21.0 on Erlang/OTP 29, one h2c connection on loopback sent 15,943 bytes of HEADERS for 100 streams. Binary memory grew by 38.4 MB and every handler received a 384,190-byte cookie header. A control with the same 100 streams and no indexed fields grew by 0."}]}}}

{}

{}

{}

{}