On June 10 this year, n8n published 15 security advisories in a single day.
Two weeks later it published nine more. Two weeks after that, another 13.
If you self-host, all 37 were decisions you had to make. Read each advisory, work out whether the affected node is one you use, test the upgrade, schedule the window.
What the 2026 record actually looks like
n8n shipped version 2.0 in December 2025 with security as the headline: task runners on by default, Code node execution isolated, arbitrary command execution turned off. That was a real response to a rough stretch of disclosures, and the defaults are better for it.
The disclosures continued anyway. Two patterns from this year matter more than any single flaw.
A fix only helps once it’s applied
On March 11, CISA added an n8n remote code execution flaw to its Known Exploited Vulnerabilities catalog and gave federal agencies two weeks to patch it. Confirmed exploitation, in the wild.
n8n had shipped the fix for that flaw in December, three months earlier. In early February, Shadowserver still counted more than 24,700 exposed instances running unpatched versions.
Some fixes needed fixing
Figure 1 · When a patch needs a patch
In February, n8n patched an expression sandbox escape rated 9.4. In July, Security Joes went back to that patch and found a way around it.
A workflow expression could resolve to the real Node.js global instead of the sandboxed one, which let a workflow editor run commands as the n8n process and reach the instance encryption key that decrypts every stored credential. They reported it on July 15 and n8n shipped fixed releases on July 22.
May had already produced the same shape of problem: one of the five critical flaws in that month’s advisory was a bypass of an XML node fix n8n had shipped earlier.
The flaws moved toward agents and MCP
The category worth watching is where the newer disclosures landed, and most of them come down to isolation between users.
June’s batch included a cross-tenant credential takeover: three endpoints that let any authenticated user hijack another user’s stored OAuth tokens, after which their workflows would run under the attacker’s identity. The same batch exposed unauthenticated browser-control sessions through an MCP transport, and a later advisory found the allowed-domains restriction on HTTP requests could be bypassed through the AI agent’s MCP connector.
Another found an authorization gap in the MCP server trigger. On an instance with an MCP server workflow using n8n’s own OAuth, a member-level user could approve their own consent against someone else’s workflow and get a working token. That workflow then runs in its owner’s project, with its owner’s credentials, while the attacker sets the inputs and reads the outputs.
That’s the same ground the governance conversation covers. If any builder can stand up an MCP server, the isolation between one builder’s agents and another’s is the control that has to hold.
Better defaults still leave you the upgrade
None of the above says n8n is unsafe to build on. Open source software gets audited, flaws get found, and a project that publishes 15 advisories at once is a project doing disclosure properly. The n8n team has been responsive, and 2.0 closed off several of the easiest attack paths for good.
What better defaults can’t do is apply themselves. A hardening release from December doesn’t help with a flaw found in July, and the shared responsibility model for self-hosted software puts every upgrade decision on whoever runs the instance.
That’s a standing commitment on someone’s calendar. The two patch bypasses this year mean applying an upgrade once doesn’t always close the item.
The severity mix shifted over the year in a way that’s easy to misread, too. Early disclosures included unauthenticated flaws exploitable from the open internet. More of the recent critical ones require an authenticated account with workflow-editing permission, which narrows the blast radius on paper. In practice, a workflow-editing account describes most of the people using the tool.
Most teams running n8n have someone who would action the next advisory. Worth knowing whether that person has the time allocated, and whether anyone would notice a batch going unread.
What changes on a managed runtime
Tray patches and monitors the runtime, so an advisory becomes a maintenance window on our side rather than a decision on yours. Logs stream to your SIEM, data is encrypted in transit and at rest, and every agent and MCP call runs through the platform’s governance layer with policy, scope, and audit applied.
| Responsibility | Self-hosted n8n | Tray |
|---|---|---|
| Applying security patches | Your team, on your timeline | Handled by the platform |
| Monitoring the runtime | You build and staff it | Continuous, included |
| Agent and MCP governance | Per-instance configuration | Policy, scope, and audit standard |
| Audit trail | Enterprise tier, self-configured | Standard, streamed to your SIEM |
| Incident response | Community forum below Enterprise | Contractual SLA |
Where to start
Whether you stay on n8n or move, these are worth answering honestly before the next advisory rather than during it.
- Who reads the n8n security advisories, and how would they find out about a new one?
- How long did your last critical upgrade take from disclosure to deployed?
- Which version are you on right now, and is it clear of everything disclosed this year?
- If a builder’s agent could reach another builder’s credentials, would anything in your setup catch it?
Anything you can’t answer cleanly is a risk you already own. The same is true of the compliance evidence question and what changes under production volume.