If you or anyone on your team can create or edit a workflow in n8n, you can currently — well, until you patch — turn that workflow into full remote code execution on the server it's running on. CVE-2026-33696, patched this month, is a CVSS 9.4 prototype-pollution bug in n8n's XML and GSuiteAdmin nodes. Every advisory says 'authenticated,' which sounds like it needs a compromised admin account. It doesn't. It needs whatever permission level your ops person, your marketing automation person, or that contractor you gave workflow access to six months ago already has.
n8n is the open-source workflow tool behind a huge share of the 'build your own AI agent at home' tutorials flooding YouTube and Reddit this year — connect an LLM API to your email, your calendar, your CRM, and let it act. That's exactly why this bug is worse than a typical self-hosted-tool RCE: n8n instances aren't just running scripts, they're holding the API keys and OAuth tokens for everything they're wired into. A shell on the n8n box isn't just a shell — it's every credential in the vault, at once.
What 'prototype pollution' actually means (for real this time)
Every object in JavaScript inherits from a shared template called Object.prototype — it's why {}.toString() works even though you never defined toString on your object. Prototype pollution abuses code that lets user input control which property gets written; if an attacker can name that property __proto__, they're not writing to their own object anymore, they're writing to the shared template every object in the entire application inherits from. Do that with the right property name and you've changed how core parts of the app behave, for every object, everywhere. It's less 'hacking a lock' and more 'reprinting the master key that every lock in the building was cut from.'
In n8n's case, GitHub's advisory traces the flaw to the XML and GSuiteAdmin node parameter handling: crafted configuration values on those nodes let an authenticated user write attacker-controlled values onto Object.prototype when the workflow saves. From there, chaining into remote code execution on the n8n host gives an attacker full read access to files, the credential store, and connected databases, plus the ability to run arbitrary commands as whatever user runs the n8n process.
Affected: n8n below 1.123.27
Affected: n8n 2.0.0-rc.0 through 2.13.2
Affected: n8n 2.14.0 exactly
Fixed: 1.123.27
Fixed: 2.13.3
Fixed: 2.14.1
n8n instances typically hold API keys and OAuth tokens for every service they're wired into — which is what makes a host-level RCE so much worse than usual. · Unsplash
Why this lands harder on the AI-agent crowd specifically
This isn't a hypothetical about some enterprise IT team. Look at how n8n actually gets adopted lately: a solo builder or small team spins up a self-hosted instance on a $5 VPS, wires it to an LLM API, a Gmail account, a Slack workspace and a database, and calls it an 'AI agent.' It's exactly the kind of setup that DeepSeek-assisted autonomous attacks are increasingly good at finding — internet-exposed, lightly monitored, holding way more access than the box itself looks like it deserves. A prototype-pollution RCE in the tool orchestrating all of that isn't a footnote, it's the whole blast radius in one instance.
Patch checklist
1
Upgrade to 1.123.27, 2.13.3, or 2.14.1 depending on which branch you're on — do this before anything else.
2
Audit who currently has workflow create/edit permission and cut it down to people who actually need it.
3
Rotate any credentials stored in n8n's vault if you can't confirm exactly when you patched relative to when the CVE went public.
4
If you're on n8n Cloud, confirm with n8n support that your instance was patched server-side — you can't apply this update yourself.
5
Review recent workflow edit history for anything nobody on your team recognizes.
n8n CVE-2026-33696 FAQ
Does this affect n8n Cloud or only self-hosted instances?
The CVE affects the n8n application itself, so both are technically exposed until patched — n8n Cloud users should confirm with n8n that server-side patching has already happened, since you can't apply the update yourself on a managed instance.
Do I need to use the XML or GSuiteAdmin node for my instance to be at risk?
Yes — the vulnerability is specifically in how those two nodes handle parameters. If neither appears in your workflows today, your exposure is lower, but you should still patch since workflows get added over time.
Can a completely unauthenticated attacker exploit this?
No. It requires an account with permission to create or modify workflows. The risk is that most n8n deployments hand that permission out more broadly than they'd hand out admin access.
What's the actual worst case if this isn't patched?
Full remote code execution on the n8n host, which typically means access to every API key and OAuth token stored in its credential vault — not just the n8n application itself.
n8n's advisory doesn't say anyone's exploited this in the wild yet, and the authentication requirement means it's not a drive-by zero-day. But 'not yet' isn't a security posture, and the same open-source AI stack getting patched here is the stack we've been tracking all year — see the LiteLLM supply-chain leak — as tooling powering the local-AI boom gets real security attention for the first time, mostly because it's finally popular enough to be worth attacking. If you're running n8n anywhere with real credentials attached, this is this week's patch to actually do, not defer. For a longer view on this pattern, see GitLab's own emergency fix from earlier this month.
