BUN · GHSA-26q8-h657-pf84 · Runtime
FIX → 1.4.4
Bun 1.4.3 and earlier ship a root certificate store that trusts intermediate certificate authorities from eMudhra (emSign) whose private keys were compromised and revoked. An attacker in the network path can present a forged certificate for any hostname and read or modify traffic, including packages downloaded by bun install.
first public Oct 23, 2026 · 1 posts · 1 source
Could this affect your app?
Free first check from your website. Connect your repo for the full answer.
Any application or tool that runs Bun 1.4.3 or earlier and makes TLS connections with the default trust store, including fetch, node:https, WebSocket, and bun install or bunx downloads. A TLS server that requests client certificates without a custom ca is affected too. Connections that pass an explicit ca list without the emSign roots are protected, and so is anyone already on 1.4.4.
Not affected if bun-1.4.4-or-later, explicit-ca-without-emsign-roots
Who cares bun, javascript, node, self-hosted, tls, typescript
bun --version and check whether it is below 1.4.4.bun build --compile executables built with an older Bun; they embed the old trust store until rebuilt.ca list that leaves out the emSign roots, since that connection is protected.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.
Bun's bundled root certificates included emSign ECC Root CA - G3. Eight eMudhra (emSign) intermediate CAs were revoked for key compromise in October 2026, and the six of them that issue TLS certificates chain to that root. Bun 1.4.3 and earlier accept certificates issued by those intermediates. The private keys have been independently recovered by multiple people and some have been disclosed publicly, so any attacker in the network path can impersonate any TLS server to Bun.
Bun 1.4.4 removes the root from the bundle and rejects any certificate chain that contains one of the eight compromised public keys.
This is a compromise of a certificate authority's keys, not a bug in Bun's certificate validation. Other projects that ship their own trust store were affected in the same way.
Any TLS client connection that uses Bun's default trust store is affected. That includes fetch, bun install, bun add, bunx, node:https, node:tls, WebSocket, Bun.connect and fetch over HTTP/3.
A TLS server that sets requestCert: true without a ca also verifies client certificates against the default trust store, so it is affected in the same way.
Bun checks revocation only against a CRL passed in the crl option, so the CA's revocation of the intermediates does not protect affected versions by default.
Executables built with bun build --compile embed the Bun runtime and its trust store. An executable built with an affected version stays affected until it is rebuilt.
An attacker in the network path can present a forged certificate that Bun accepts as valid for any hostname. They can then read and modify the traffic. For bun install and bunx this includes the packages that are downloaded.
Upgrade to Bun 1.4.4, and rebuild any bun build --compile executables with it.
Bun 1.4.4 has two changes:
emSign ECC Root CA - G3, emSign Root CA - C1 and emSign ECC Root CA - C3. emSign Root CA - G1 stays in the bundle, as it does in NSS 3.131.1.CERT_REVOKED (#46300). The check matches the key rather than the certificate, and it applies whichever root the chain ends at. It therefore also covers cross-signed copies of the intermediates, roots loaded from the system store, NODE_EXTRA_CA_CERTS, SSL_CERT_FILE, SSL_CERT_DIR, and a ca option. It applies to TLS over TCP, the HTTP/3 client and node:quic, and to client certificates that a server verifies. fetch over HTTP/3 reports the failure as HTTP3HandshakeFailed. The list of keys is the one Node.js, Go and Chrome block.There is no process-wide workaround for affected versions.
--use-system-ca and NODE_USE_SYSTEM_CA=1 do not help. They add the system's certificates to the bundled ones and do not replace them.ca (or tls.ca) on a connection replaces the default trust store for that connection only. A list that leaves out the emSign roots protects that connection.bun install --cafile <path> (or --ca) does the same for that install. bunx does not accept those flags before 1.4.4.cafile under [install] in bunfig.toml does the same for bun install. In ~/.bunfig.toml it also applies to bunx.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.