Files
windmill/backend/windmill-worker
Ruben FiszelandClaude Opus 4.8 c029d6dcde fix(security): drop --allow-run from Deno sandbox (GHSA-gj6h-vw66-mr8f) (#10039)
The `// sandbox` annotation (and global nsjail sandboxing) restricted Deno to
`--allow-run=git,/usr/bin/chromium`. Both binaries can be coerced into spawning
`/bin/sh`, escaping Deno's permission model:

- git via hook configs, e.g. `git -c core.fsmonitor='/bin/sh -c <cmd>' status`
- chromium via subprocess-launcher flags, e.g. `--renderer-cmd-prefix` /
  `--gpu-launcher`, pointed at a launcher the script writes into `./`

Because the subprocess is spawned by git/chromium — not Deno — it is invisible
to Deno's permission checks, giving any user with script-execution permission
arbitrary OS command execution (root, in the default worker container).

Critically, the Deno runtime is the ONE language never wrapped in nsjail (there
is no run.deno.config.proto; every other language has one). So for deno the Deno
permission model is the *entire* sandbox — there is no OS-level containment to
fall back on, and handing it any subprocess-spawning binary is an unconditional
escape regardless of the nsjail setting.

Fix: emit no `--allow-run` in the restricted path, denying all subprocess
execution. The advisory's alternative (inject `-c core.fsmonitor=false ...`)
doesn't apply — the user controls the git/chromium argv, so any injected
hardening is overridden. Admins who accept the risk (e.g. puppeteer) can still
re-add specific binaries via `DENO_FLAGS`.

Verified with both PoCs on a running worker: git and chromium invocations now
return `Requires run access to "<bin>"`; the sandbox escapes are closed.

Fixes WIN-2151

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-10 13:33:22 +00:00
..

Windmill Worker

The worker. Used to process and execute flows & jobs.

This crate exposes both a library as well as a binary target.