CVE-2026-21877: Max-Severity n8n Bug Turns “Low-Privilege” Access Into Full Remote Code Execution

A newly disclosed maximum-severity vulnerability in the workflow automation platform n8n is raising alarms because it can convert ordinary authenticated access into full remote code execution on the server running the automation stack. Tracked as CVE-2026-21877 and scored CVSS 10.0, the bug affects both self-hosted deployments and n8n Cloud instances, placing many production automation environments on an uncomfortable timeline: patch quickly, or assume compromise is possible if any account is exposed.

The security issue lands at a particularly sensitive moment for automation platforms. Tools like n8n are often trusted with API keys, database credentials, cloud tokens, chatops hooks, ticketing systems, and internal admin workflows. In other words, they are not “just another web app”. They frequently sit in the middle of everything.

What is CVE-2026-21877?

CVE-2026-21877 is an authenticated remote code execution vulnerability. In practical terms, a user who can log in to an affected n8n environment can, under certain conditions, manipulate application behavior so that the n8n service ends up executing attacker-controlled code. The published CVSS vector highlights why defenders are treating it as urgent: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H.

The “PR:L” detail is the part that catches many security teams off guard. This is not a vulnerability that requires administrative privileges, and it does not require another user to click anything. If an attacker gains or abuses a low-privilege account, the pathway to system-level impact becomes realistic.

Who is affected?

n8n versions 0.123.0 and later, up to but not including 1.121.3 are impacted. The fix is available in n8n 1.121.3 and newer. Organizations running older long-lived instances are especially exposed if they have multiple workspace users, broad workflow creation rights, or internet-facing access without strict identity controls.

This matters beyond the n8n host itself. Many deployments connect n8n to internal services and privileged automation accounts, so an attacker who gets code execution can often pivot into adjacent systems, extract secrets, or quietly manipulate business workflows.

How the exploit chain works in real deployments

High-level descriptions of the flaw point to an arbitrary file write condition being abused to reach code execution. Reporting around the root cause links the issue to how a workflow node can be coerced into writing attacker-controlled content to sensitive locations, followed by execution by the service runtime.

In environments where n8n is deployed with broad filesystem permissions, or where the service user can write into directories that influence runtime behavior, “file write” issues quickly become “run my code” issues. That is why these bugs are so dangerous: defenders can mistakenly treat them as a data integrity problem, when the real outcome is host takeover.

Why CVSS 10.0 is not just a number

A 10.0 rating is rare, and it signals a combination of factors that security teams dread: network-reachable, low complexity, no user interaction, and high impact across confidentiality, integrity, and availability. If n8n is exposed to the internet and a valid login is obtained, exploitation can be quiet and fast.

The operational risk is also unusually high because n8n frequently runs mission-critical automations: incident response enrichment, ticket creation, finance notifications, CI/CD glue steps, CRM sync, or chat-based approvals. An attacker who can change workflows does not always need to destroy anything to cause damage. Subtle tampering can be enough.

Practical attack scenarios defenders should model

Security teams are already familiar with credential theft and session hijacking, but n8n raises the stakes because authenticated access can be easy to come by in sprawling environments. Consider a few realistic pathways: a reused password on an n8n account, a compromised SSO identity, a contractor account that was never removed, or an internal user whose machine is infected.

Once an attacker is inside, they may not immediately “go loud” with obvious commands. Instead, they can create or modify workflows to collect secrets, reroute data, or add hidden steps that exfiltrate records. With RCE available, they can also pivot into the underlying host, enumerate environment variables, scrape mounted volumes, or access metadata services in cloud deployments, depending on network configuration.

Fix status and patch guidance

The vulnerability is patched in n8n 1.121.3. The safest remediation is straightforward: upgrade to 1.121.3 or later across all environments, including dev, staging, and any “forgotten” utility instances that often sit outside normal patch cycles.

If you run n8n in containers, treat this like a full rebuild event. Pull updated images, redeploy, and rotate any secrets that were accessible to the automation service, especially if the instance was internet reachable or had many users.

If you cannot patch immediately

Upgrading remains the recommended path, but temporary mitigations can reduce exposure while teams work through change control. Guidance associated with the advisory includes disabling the Git node to shrink the attack surface and tightening access so that untrusted or low-privilege users cannot build or modify sensitive workflows.

Treat these mitigations as a short bridge, not a solution. A max-severity issue like this is precisely the kind of vulnerability attackers watch for because automation platforms are high-value and often under-monitored compared to traditional enterprise apps.

Indicators and telemetry to watch

This vulnerability does not come with a neat list of “known bad” IPs or hashes. Still, defenders can increase the chance of catching abuse by monitoring for behaviors that do not match normal automation usage, particularly around workflow changes and filesystem side effects.

• Unusual workflow edits: new or modified workflows by accounts that rarely create automations, especially outside business hours.
• Suspicious node usage: sudden introduction of nodes that touch the filesystem, execute code, or interact with Git-related functionality where it is not normally used.
• Unexpected write activity: new directories, repositories, or files created by the n8n service user in paths that are not part of routine operations.
• Process execution signals: child processes spawned from the n8n runtime that do not align with standard integrations.
• Secrets access spikes: bursts of credential reads, token usage, or outbound connections from the n8n host to unfamiliar endpoints.

Hardening moves that pay off even after patching

Patches close the immediate hole, but automation platforms remain a prime target because they connect to everything. A few defensive design decisions can reduce the blast radius of the next bug: run n8n with minimal filesystem permissions, isolate it in a segmented network zone, restrict outbound egress where feasible, and enforce strong identity controls such as SSO with MFA and tight session policies.

Finally, reduce who can build “powerful” workflows. Many teams default to convenience and grant broad workflow creation rights. For n8n, that convenience can become a security liability. Even without a vulnerability, excessive workflow privileges can enable data misuse. With a vulnerability like CVE-2026-21877, the consequences escalate sharply.