Between February 4 and March 25, n8n disclosed three waves of security advisories covering eighteen CVEs. Most rated critical or high. The throughline was not surprising: expression evaluation and the workflow-author privilege boundary are where a self-hosted automation platform actually lives or dies.

Wave one landed February 4 with ten advisories (n8n bulletin posted Feb 6). The headline issue was CVE-2026-25049, CVSS 9.4: an authenticated user with workflow-create permission could escape the expression sandbox and run system commands on the host. It was a bypass of CVE-2025-68613, CVSS 9.9, which n8n had patched in December 2025. Same defect class, slightly different shape.

Wave two on February 25 was worse. The bulletin listed seven advisories, five critical. CVE-2026-27577 was another expression sandbox escape (CVSS 9.4, GHSA-vpcf-gvg4-6qwr). CVE-2026-27495 broke out of the JavaScript task runner. CVE-2026-27494 broke out of the Python code node. CVE-2026-27497 was RCE via the Merge node. CVE-2026-27493 let an unauthenticated user evaluate expressions through the Form node. Three sandbox escapes and one auth-bypass in a single bulletin is a pattern, not a coincidence.

Wave three was CVE-2026-33749 on March 25: stored XSS in /rest/binary-data, exploitable by a workflow author against an admin's browser session. Credential exfiltration and privilege escalation, both with valid session cookies.

The lesson for anyone running n8n at home or as part of an agent stack is the same one I wrote about for MCP two weeks ago, and the same one JonBot Pt 1 was already circling: a low-code automation platform is a code execution engine with a friendly UI. Workflow-create permission is production-admin equivalent. The webhook surface is unauthenticated by design. Treating either as a normal application permission is the underlying mistake the CVE waves keep punishing.

I made three changes. All three were reactive. Wave one was the trigger and most of the work landed in the first 48 hours; wave two pushed me to extend the second change further than I had planned; wave three did not require new architecture because the editor was already off the public internet by then.

Patch cadence first. Patches shipped the same day as each bulletin. I moved my instance from 1.x to 2.9.3 during wave two and to 2.13.x after wave three. The cost of staying current was low. The cost of running anything older was a public exploit chain. This is not a change so much as an acknowledgment that "I will patch when I get to it" is not a defensible posture for software that evaluates user-supplied expressions as a core feature.

Workflow-create permission collapsed to one account. n8n's native RBAC has Owner, Admin, and Member roles, and workflow-create is bundled into all three by default. There is no out-of-the-box way to separate "can run a workflow" from "can author a workflow." So I demoted the second account I had been using for ad-hoc work to a custom role with execution and read-only credential access, and I left exactly one Owner account. That account requires a hardware security key (YubiKey) for the underlying Google Workspace identity, and the n8n login itself sits behind that same identity. Sandbox escapes still matter, but the population of users who can stage one is now exactly me, with no password-only path. The rougher edge is that scheduled workflow edits now block on me being available; for a single-operator instance that is a fine trade.

The editor moved behind Cloudflare Access. Webhooks remain public because they have to be. The editor does not, and there is no good reason a stored-XSS payload should be reachable from the open internet. The Access policy is narrow: identity must be a Google Workspace account on my own domain, sessions are short-lived, and the device must report through WARP with a passing posture check. The data plane (/webhook/*, /webhook-test/*) is excluded from the policy. The management plane (/, /rest/*, the editor UI) requires the full identity-plus-posture check on every session. Putting the management plane behind an identity-aware proxy and leaving the data plane public is the same pattern I use for every other internal service. n8n was the last one I had not split.

None of this makes the platform invulnerable. It makes the failure modes ones I can reason about. The next n8n bulletin will land. When it does, the question I want to answer is "did anyone exploit this in the four hours before I patched," not "did anyone exploit this in the four months I left workflow-create open to five accounts."

See also

References

[1] The Hacker News. "Critical n8n Flaw CVE-2026-25049 Enables System Command Execution." February 5, 2026. https://thehackernews.com/2026/02/critical-n8n-flaw-cve-2026-25049.html

[2] n8n Community. "Security Bulletin: February 6, 2026." February 6, 2026. https://community.n8n.io/t/security-bulletin-february-6-2026/261682

[3] n8n Community. "Security Bulletin: February 25, 2026." February 26, 2026. https://community.n8n.io/t/security-bulletin-february-25-2026/270324

[4] SentinelOne. "CVE-2026-33749: n8n Workflow Automation XSS Vulnerability." March 27, 2026. https://www.sentinelone.com/vulnerability-database/cve-2026-33749/

[5] NIST National Vulnerability Database. "CVE-2025-68613 Detail." December 19, 2025. https://nvd.nist.gov/vuln/detail/CVE-2025-68613