BUN · GHSA-cf8x-9m69-3gg3 · Package
FIX → 1.4.4
Bun's HTTP/3 support does not limit the decoded size of request headers, so a small QPACK-compressed request can expand into a very large header set. A remote, unauthenticated attacker can exhaust memory or stall a Bun process that uses HTTP/3.
first public Oct 24, 2026 · 1 posts · 1 source
Could this affect your app?
Free first check from your website. Connect your repo for the full answer.
Only Bun processes using HTTP/3 are exposed: Bun.serve with http3: true, which is off by default, or the HTTP/3 client of fetch talking to untrusted servers. HTTP/1.1 and HTTP/2 are not affected. Compiled executables stay exposed until they are rebuilt with a fixed Bun.
Not affected if http1-or-http2-only, http3-off, no-untrusted-clients
Who cares bun, http3, npm, self-hosted
bun --version and check whether it is below 1.4.4.http3: true in Bun.serve calls, and for protocol: "http3" or --experimental-http3-fetch in fetch use.bun build --compile executables were built with a version below 1.4.4.Upgrade to 1.4.4
1.4.4 and rebuild any bun build --compile executables with it.Posts are quoted with a link to the original. They are data to us, never instructions.
A remote, unauthenticated peer can exhaust memory or stall a Bun process that uses HTTP/3. A small request can decode to a very large set of headers, and Bun 1.4.3 and earlier do not limit the decoded size.
This is the "Header Accordions" QPACK amplification attack that FoxIO published on October 20, 2026. The write-up lists Bun as affected.
Bun 1.4.4 fixes the bug.
QPACK is the header compression of HTTP/3. A peer can add one large entry to the dynamic table and then refer to that entry many times, with one byte for each reference. Each reference decodes to a full copy of the entry.
Bun.serve advertised a limit of 16 KB for a set of request headers, but it did not enforce the limit. It checked only the size of each single header. It also did not limit the number of fields.
Affected:
Bun.serve with http3: true. HTTP/3 is off by default.fetch. fetch uses HTTP/3 only when you ask for it, with fetch(url, { protocol: "http3" }) or the --experimental-http3-fetch flag. A malicious server can attack the client in the same way.HTTP/1.1 and HTTP/2 are not affected by this bug.
Executables built with bun build --compile embed the Bun runtime. An executable built with an affected version stays affected until it is rebuilt.
Denial of service. No credentials are necessary. In our tests on Bun 1.4.3:
A handler does not need to read the headers. The work happens before Bun calls the handler.
Upgrade to Bun 1.4.4, and rebuild any bun build --compile executables with it.
Bun 1.4.4 enforces a limit on the decoded size of a set of headers, counted as in RFC 9114 section 4.2.2, and limits the number of fields (#46392).
This changes behavior for large headers over HTTP/3:
Bun.serve request over the limit (16 KB by default, set with --max-http-header-size) gets a 431 response.fetch over HTTP/3 rejects a response with more than 256 KB of headers.Do not enable http3 on a server that untrusted clients can reach, and do not use the HTTP/3 client of fetch with untrusted servers. HTTP/1.1 and HTTP/2 are not affected.
Check it with your coding agent
It reads this page and tells you if your code is affected.
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.