Automation · 3 min read
Audit and Patch Your Self-Hosted n8n Instance Against the Sandbox-Escape Vulnerability
n8n's Code node and expression editor run inside a sandbox specifically so that a workflow can't reach out and touch the host it's running on. In July 2026, n8n patched a high-severity bypass of that sandbox: crafted arrow-function expressions could escape it entirely and execute arbitrary operating-system commands with the privileges of the n8n process. Rated High with a CVSS 4.0 score of 8.7, no CVE number had been assigned as of the advisory's publication.
This walkthrough is for self-hosted instances you manage yourself — Docker or npm/pnpm installs. If you're on n8n Cloud, patching is handled for you.
Who's affected
Exploiting this requires an authenticated account with permission to create or modify workflows — it's not an unauthenticated, drive-by attack. But in many self-hosted setups that's a wide net: any teammate with workflow-editor access (not just admins) could trigger it, and a successful exploit runs commands as the n8n process itself, which can expose N8N_ENCRYPTION_KEY and, through it, every credential n8n has stored.
Affected versions: anything below 2.31.5, plus the 2.32.0 release specifically.
Patched versions: 2.31.5 and 2.32.1 onward.
Notice the gap: 2.32.0 shipped after 2.31.5 but was itself vulnerable — patch level alone doesn't tell you the answer, you need the actual version string.
Step 1: Check your installed version
npm/pnpm install:
n8n --versionDocker:
docker exec <container-name> n8n --versionStep 2: Run it against the affected ranges
Rather than eyeball the version number against two separate ranges, this script does the comparison for you and exits non-zero if you're exposed:
#!/usr/bin/env bash
# Checks an n8n version string against GHSA-gv7g-jm28-cr3m's affected ranges:
# vulnerable: <2.31.5 OR >=2.32.0,<2.32.1
set -euo pipefail
version="${1:?Usage: check-n8n-version.sh <n8n-version>}"
ver_lt() {
[ "$1" = "$2" ] && return 1
lower=$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)
[ "$lower" = "$1" ]
}
ver_ge() { ! ver_lt "$1" "$2"; }
if ver_lt "$version" "2.31.5"; then
echo "VULNERABLE: $version is below 2.31.5"
exit 1
elif ver_ge "$version" "2.32.0" && ver_lt "$version" "2.32.1"; then
echo "VULNERABLE: $version is in the 2.32.0 pre-patch range"
exit 1
else
echo "OK: $version is patched against GHSA-gv7g-jm28-cr3m"
exit 0
fiSave it as check-n8n-version.sh, then pipe your actual version straight in:
chmod +x check-n8n-version.sh
./check-n8n-version.sh "$(n8n --version)"
# or, for Docker:
./check-n8n-version.sh "$(docker exec <container-name> n8n --version)"Step 3: Patch
Docker / Docker Compose — pin the image tag to a patched version and redeploy:
# docker-compose.yml
services:
n8n:
image: n8nio/n8n:2.32.1 # or 2.31.5 if you need to stay on the 2.31.x traindocker compose pull
docker compose up -dnpm/pnpm global install:
npm install -g n8n@2.32.1Step 4: Confirm the patch took
Re-run the same check — it should now report OK:
./check-n8n-version.sh "$(n8n --version)"If you can't upgrade right away
The advisory's own workaround, worth noting because it's only partial: restrict workflow creation and editing to accounts you fully trust, since exploitation requires that permission. It doesn't close the hole — anyone who still has editor access can still trigger it — so treat it as a stopgap until you patch, not a substitute for patching.
If keeping up with patches like this one indefinitely isn't something you want to own yourself, n8n Cloud handles this one — and every future one — for you automatically.
Disclosure: the n8n Cloud link above is an affiliate link — if you sign up through it, we may earn a commission at no extra cost to you. See our affiliate disclosure for details.
What's next
If you're running n8n behind the MCP Server Trigger setup, the same principle applies doubly: an MCP client that can create or edit workflows through that surface has the same permissions this vulnerability requires, so keep both patched and access-scoped together.