WASI implementation silently overwrites a shared fs instance

[mattfysh]

bun/src/js/node/wasi.ts

Line 802 in 6352b79

fs = bindings.fs;

Is this the intended design? it makes it impossible to create proper isolation between WASI instances

Furthermore, it seems insecure to allow the fs binding shared across all WASI instances to simply be silently overwritten on each call to new WASI

[yhay81]

No — not if bindings is meant to belong to one WASI instance. This is shared mutable module state, and the current main branch still has it.

The important detail is that the bundled wasi-js module declares one let fs in the CommonJS factory. Every constructor then assigns that same binding here:

this.bindings = wasiConfig.bindings || defaultConfig.bindings;
const bindings = this.bindings;
fs = bindings.fs;

The functions stored in this.wasiImport dereference fs later, when a syscall runs (for example fd_close, path_open, path_readlink, etc.). fstatSync() also reads the module-scoped value. Consequently this sequence is unsafe:

1. Construct instance A with adapter fsA.
2. Construct instance B with adapter fsB.
3. Invoke a filesystem syscall through A.

Step 3 can call fsB, because B's constructor was the most recent writer. A's FD_MAP remains instance-local, so this line alone is not automatically an arbitrary host-filesystem escape. It does break backend isolation, though, and can cross a security boundary if the adapters expose different roots or tenants.

Until it is fixed, I would avoid using differently configured WASI instances in the same Bun process; use one shared FS adapter or separate processes.

A robust fix would be to remove the module-level fs entirely:

• make the imports use this.bindings.fs (or an instance-local accessor),
• make class methods such as fstatSync() do the same,
• make setState() update this.bindings rather than any shared identifier,
• add a regression test that creates A/fsA, then B/fsB, calls an A syscall, and asserts only fsA was invoked.

Simply changing line 802 to a constructor-local const fs would fix the closures created in the constructor, but not methods outside that scope, so those need auditing too.