Bun is prone to supply chain attacks?

[saksham-malhotra]

Being a part of an organisation where installation and usage of Bun is blocked, I am reaching out using my personal account.

Recently, there was an advisory published within our organization about vulnerabilities of using Bun and it was completely banned. Their explanation is below.

---

Recent supply chain attacks have demonstrated how attackers can exploit JavaScript runtimes during dependency installation and execution. These attacks are directly impacting developer environments.

What does this look like in practice?
Malicious package execution during install
Attackers publish compromised or lookalike packages. When a developer runs bun install, hidden scripts can execute automatically.
Impact:
Unauthorized code runs on your machine
Sensitive data (tokens, SSH keys, environment variables) can be exfiltrated
Persistent backdoors can be installed
Supply chain propagation risk
If compromised dependencies are executed through Bun, there is a risk of propagation into development workflows.
Impact:
Malicious code could enter build or development environments
Broader downstream risk if not contained

---

I would like to understand how vulnerable this actually is and are there any steps being taken by the Bun community to mitigate this?

[sueun-dev]

the advisory is half right, worth pinning down which half. npm runs every dep's install scripts by default. bun doesn't for unknown packages: it blocks their preinstall/install/postinstall, lists them under bun pm untrusted, and makes you opt in with trustedDependencies or bun pm trust <pkg>.

i tested a lookalike-style local dep with a postinstall. bun install gave 'Blocked 1 postinstall' and it never ran. the same dep on npm install ran it. so for the typosquat/unknown-package vector the advisory names, bun is stricter than npm, not looser.

the catch: bun ships a large built-in trusted list of popular packages (esbuild, sharp, puppeteer, bcrypt...) whose scripts DO run automatically with no prompt and don't show up in bun pm untrusted. a compromised version of one of those still auto-runs on install. so bun shrinks the install-time surface but isn't zero-trust. --ignore-scripts, lockfile pinning, and auditing that trusted set are the levers if your org wants belt-and-suspenders.

[RiskyMH]

Yeah what @sueun-dev said. Additionally you can block it fully in a global bunfig or per project if you really don't want it:

https://bun.com/docs/pm/lifecycle#ignore-scripts

the catch: bun ships a large built-in trusted list of popular packages

its only 367: https://github.com/oven-sh/bun/blob/main/src/install/default-trusted-dependencies.txt