n8n patches sandbox escape that let editors run OS commands

A patch just landed for a bug in n8n, the open source workflow tool that has quietly become default plumbing for a lot of small-team AI agents. The Hacker News reports that the maintainers fixed a high-severity expression-sandbox escape, tracked as GHSA-gv7g-jm28-cr3m and rated 8.7 under CVSS 4.0, that let an authenticated workflow editor execute operating-system commands with the privileges of the n8n process itself.

The exploit path is the sort of thing you file under 'sandbox escapes are hard.' Security Joes, the firm that found the flaw, discovered that a concise arrow body such as `() => process` could resolve `process` to the real Node.js global, and that the property checker inspected static names but still accepted `Reflect.get()` calls whose target property came in as a function argument. Chain the two together and you get real `process` plus a way to reach `getBuiltinModule` and load `child_process`. As the Security Joes research team put it, 'Neither alone is sufficient. Neither was covered by tests.'

What raises this above the usual weekly CVE noise is where it was found. Security Joes went looking for it while probing n8n's February fix for CVE-2026-27577, a 9.4-rated sandbox escape the project had already patched. So this is a bypass of a bypass fix, on the same expression sandbox. Successful exploitation can expose `N8N_ENCRYPTION_KEY` and allow decryption of the credentials n8n stores, which in an agent-orchestration setup usually means the keys to every downstream service the workflows touch.

The timeline is tight: identified July 14, reported July 15, patches shipped July 22 for affected ranges below 2.31.5 and between 2.32.0 and 2.32.1. As of July 27, no CVE has been assigned. The advisory notes that n8n's interim guidance to restrict instance access and workflow editing to trusted users is an incomplete, short-term mitigation, so an actual upgrade is the real answer.

The honest caveat is that this needs an authenticated editor to fire, which sounds like a high bar until you remember how many teams share a single self-hosted n8n behind a shared login. What the reporting does not give you is any in-the-wild exploitation data or a count of exposed instances. The upside, if there is one, is that self-hosted AI-agent runtimes are now getting the same style of adversarial scrutiny that CI runners and IDE plugins got a few years back, and that is overdue.