Security researchers at Striga discovered a critical vulnerability chain in n8n, the popular open-source workflow automation platform, that allows any authenticated user with workflow editing permissions to execute arbitrary code on the server. The combined exploit scored a 9.4 out of 10 on the CVSS severity scale.
How the Exploit Works
n8n lets users write expressions inside workflow nodes - think simple formulas that reference data from other steps. These expressions run inside a sandbox meant to prevent access to dangerous JavaScript features. The vulnerability chains two separate flaws to break out of that sandbox.
The first flaw: n8n's PrototypeSanitizer blocks direct references to dangerous classes like Function, but only when they appear as plain identifiers. Wrapping the reference in a function call - class Z extends (() => Function)() {} - slips past the check because the sanitizer sees a function call, not a direct reference.
The second flaw: workflow node names get inserted directly into expression strings without any sanitization. The code uses template literals (string templates that insert variables) to build expressions, meaning whatever you name a node becomes executable code.
Chain them together: rename a workflow node to include the sandbox escape payload, and when n8n evaluates the expression, it runs your code with full server access. That means reading environment variables, database credentials, and running system commands.
Patch Timeline and What to Do
Striga reported the vulnerability to n8n on February 10, 2026. The patch shipped February 25, 2026. n8n Cloud instances were patched automatically.
Self-hosted n8n deployments need a manual update. If you're running n8n on your own infrastructure and haven't updated since late February, do it now. Any user with workflow editing permissions - not just admins - could exploit this. In organizations where multiple team members share an n8n instance, that's a significant attack surface.
The vulnerability is a good reminder that "authenticated" doesn't mean "trusted" when it comes to security boundaries. Expression sandboxes are notoriously hard to get right in JavaScript, and n8n isn't the first tool to learn that lesson.