n8n security update: 5 vulnerabilities to patch now

The n8n security update published on November 13, 2026 covers five advisories, and if you self-host n8n you should plan an upgrade this week. Two are rated high: one lets a member take over pending user accounts, the other lets a user with a custom role take over the instance owner. The other three are moderate, but one of them is the kind that bites real workflows: node parameters that let a webhook caller reach API endpoints the workflow was never meant to touch.

n8n Cloud instances are patched automatically. Self-hosted instances are not.

I work on security at erxes, where we build workflow automation and integrations into a CRM. So I read these advisories less as "n8n has bugs" and more as a checklist of mistakes every automation platform can make. Here is what the five n8n vulnerabilities are, which versions you need, and what I'd check on your instance today.

What the n8n security update fixes

The list comes from n8n's security update post on the community forum and the matching GitHub security advisories.

Advisory	Severity	What it allowed
GHSA-m7qq-gm3x-v79g	High (7.7)	A member could set the password on a pending invited account and log in as it
GHSA-q8rc-7m84-mfvj	High	A custom role with user management could reset or change the owner account
GHSA-h59h-rf6m-7jp5	Moderate (5.3)	Activating a workflow could use another user's credential in a trigger
GHSA-g333-hr44-g82p	Moderate (5.3)	AWS Bedrock nodes skipped SSRF protection for custom endpoints
GHSA-c772-hjfp-gfc2	Moderate (5.3)	Unencoded IDs in node parameters could redirect authenticated API calls

Every one of them needs some access to the instance first. None is an unauthenticated internet-wide bug. That lowers the urgency for a single-user install, but most teams run n8n with several members, and that's exactly where these issues live.

Account takeover: invitations and the owner account

The invitation advisory is the cleanest example of a classic bug. The endpoint that lets an invited user set up their account accepted any inviter and invitee user IDs, with no signed invitation token. A member who could list users could read a pending account's ID, set its password, and log in as that user. If the pending invite had the admin role, the attacker became admin.

The fix for this one shipped earlier, in 1.123.90 and 2.14.0, so any current patch release covers it.

The owner account advisory is subtler. n8n protected the owner from changes by other users, but the password reset link and role change operations didn't apply that protection to users with a custom instance role. Give someone a custom role with user management permissions and they could get a reset link for the owner. Full control of the instance follows.

What I take from both: authorization checks drift when a product adds new paths to the same action. Invitations, password resets and custom roles are all "who can change this user" questions. If each path does its own check, one of them will forget the special case.

Credentials used by people who can't see them

In the workflow activation advisory, activating a workflow registered its trigger nodes with the connected services using the credentials on those nodes. Activation never checked that the person publishing had access to those credentials.

So a member who knew another user's credential ID could build a workflow around it and activate it. n8n would then create or delete webhooks on the connected service (GitLab and GitHub are the examples n8n gives) with that credential's privileges, and send events to the member's workflow.

This is the same lesson I wrote about with agent payment tokens: a credential reference is not permission. Knowing an ID should never be enough to use what it points at.

SSRF and path tricks in integration nodes

The other two are about where requests go.

The AWS Bedrock advisory covers the Bedrock Chat Model and Embeddings nodes. An AWS credential could set a custom runtime endpoint, and requests to it skipped n8n's SSRF protection. A member who could create that credential could point it at an internal address, and the start of the response showed up in the node error.

The integration nodes advisory is the one I'd worry about most in practice. Several nodes built the URL path of API requests from parameters like record, table or resource IDs without encoding them. A value with relative path segments could change which endpoint of the same service got called. If your workflow feeds a webhook body into one of those fields, an outside caller could read, modify or delete resources outside the workflow's scope, using the node's stored credential.

That one doesn't need a malicious member. It needs a public webhook and a workflow that trusts its input.

How to fix it on a self-hosted n8n

Check your version and release line, then upgrade using n8n's update guide. The minimums are 1.123.96, 2.47.6, 2.48.3 or 3.2.2.
Delete any pending invitations that were never accepted, and send fresh ones after the upgrade.
Review custom instance roles. Remove user management permissions from anyone who isn't fully trusted, and turn on two-factor authentication for the owner.
Audit active workflows for trigger nodes that use credentials owned by someone else, and check GitLab, GitHub and similar services for webhooks you don't recognize.
Find workflows that pass webhook data into ID fields of integration nodes. Validate those values, and scope each credential to only the resources the workflow needs.
Block outbound traffic from the n8n host to internal addresses it has no reason to reach.

Steps 2 to 6 are n8n's own suggested mitigations, and the advisories are clear that they reduce the risk without removing it. Upgrading is the fix.

What this means if you build automation tools

We ran into similar design questions while building the AI agent platform in erxes. Workflow tools hold a lot of credentials and run code on behalf of many users, and the dangerous bugs are rarely exotic. They're missing ownership checks, special cases one code path forgets, and untrusted strings dropped into URLs.

If I had to boil this update into rules for my own team: check permission on use, not just on creation. Put "can this user change that user" in one place. Encode every path segment that comes from data. And run outbound requests through the same SSRF guard no matter which node or credential sets the URL.

FAQ

Is n8n Cloud affected by the November 13 vulnerabilities?

No action is needed on n8n Cloud. n8n says cloud instances are patched automatically.

Which n8n version fixes these vulnerabilities?

1.123.96 on the v1 line, 2.47.6 on stable, 2.48.3 on beta, and 3.2.2 on v3, or anything newer on the same line.

Can these n8n vulnerabilities be exploited without logging in?

The account takeover, credential, and Bedrock issues all need an existing user on the instance. The integration nodes issue can be triggered by an outside caller when a workflow passes untrusted webhook input into a resource ID parameter.

Sources

Cover image: n8n