Critical n8n Flaws Enable RCE and Credential Exposure

Critical n8n flaws enable RCE and credential exposure | 2026

Executive Summary

Two critical n8n flaws disclosed in March 2026 significantly raise risk for both self-hosted and cloud deployments. CVE-2026-27577 is a sandbox-escape vulnerability that can let an authenticated user with workflow-edit permissions achieve remote code execution on the host. CVE-2026-27493 is an unauthenticated expression-evaluation flaw in public Form nodes that can be chained into shell command execution. Researchers warned that successful exploitation could expose the N8N_ENCRYPTION_KEY, allowing attackers to decrypt stored secrets and potentially pivot into broader credential theft and environment compromise.

For defenders, the key issue is not just a single bug. It is the combination of public form exposure, expression injection, sandbox escape, and the possibility of turning an automation platform into a host-level exploit path. Organizations using n8n for internal integrations, cloud workflows, or customer-facing forms should treat patching and permission review as an urgent priority.

What happened?

According to public disclosures from Pillar Security, GitHub advisories, and n8n, the issue set includes two headline flaws and two additional critical weaknesses fixed in the same release cycle:

• CVE-2026-27577 — expression sandbox escape leading to RCE
• CVE-2026-27493 — unauthenticated expression evaluation via Form nodes
• CVE-2026-27495 — code injection in the JavaScript Task Runner sandbox
• CVE-2026-27497 — code execution and arbitrary file write via Merge node SQL query mode

The most serious chain starts with a public form endpoint. If exposed with the right preconditions, an attacker can submit a crafted payload that gets evaluated as an expression. If that expression then reaches the sandbox-escape flaw, the result may be arbitrary command execution on the n8n host.

Researchers also highlighted a second-order risk: once code execution is achieved, attackers may be able to retrieve the N8N_ENCRYPTION_KEY and use it to decrypt secrets stored by the platform. In practice, that could include API keys, database credentials, cloud tokens, or OAuth material held inside n8n workflows.

Why this matters for defenders

1. Public forms become an attack surface

n8n Form nodes are designed to be reachable without authentication. That makes them useful for business workflows, but also dangerous when expression handling can be manipulated by untrusted input.

2. Workflow permissions matter more than teams expect

The authenticated flaws show that “workflow editor” access should be treated as high trust. In many environments, users allowed to create or modify workflows effectively sit much closer to privileged code execution than administrators realize.

3. Secret exposure can outlive the initial intrusion

If the attacker obtains the N8N_ENCRYPTION_KEY, the blast radius is bigger than the initial host compromise. Stored credentials can unlock databases, SaaS tenants, and downstream automations. This is where strong encryption, secrets hygiene, and post-incident credential rotation become critical.

Affected versions and fixes

Public advisories indicate the flaws affect both self-hosted and cloud deployments of n8n.

Patched releases called out in the disclosures include:

• 2.10.1
• 2.9.3
• 1.123.22

Organizations should confirm the exact fixed branch that matches their installed version and upgrade path. If a team is not yet on one of the remediated releases, they should assume elevated risk until verified otherwise.

Immediate actions to take

🔴 Patch n8n immediately

Upgrade to a fixed release as fast as operationally possible. For externally exposed n8n instances, this should be treated as an emergency change window.

🔴 Restrict who can build or edit workflows

Review user roles and remove workflow creation or editing rights from anyone who is not fully trusted. Treat workflow-edit access as privileged access.

🔴 Review public Form nodes

Identify which workflows expose public forms and assess whether those endpoints are necessary. If they are not essential, disable or remove them.

🟠 Apply temporary mitigations if patching is delayed

n8n recommends temporary workarounds such as:

• disabling Form nodes with n8n-nodes-base.form
• disabling Form Trigger nodes with n8n-nodes-base.formTrigger
• using external runner mode for the JavaScript Task Runner issue
• disabling Merge nodes with n8n-nodes-base.merge where needed

These are stopgaps, not full remediation.

🟠 Rotate and review credentials after suspected exposure

If there is any sign of exploitation, assume stored secrets may be compromised. Rotate API keys, database passwords, OAuth tokens, and integration credentials. Then review downstream systems for suspicious use.

🟠 Harden host and network boundaries

n8n instances should run with restricted OS privileges and strong network segmentation. Limit outbound access where possible and avoid running automation platforms with unnecessary host-level permissions.

Detection and investigation pointers

Security teams should look for:

• unusual requests hitting public n8n form endpoints
• suspicious expression payloads in form submissions or workflow parameters
• unexpected shell command execution on n8n hosts
• access to environment variables, especially N8N_ENCRYPTION_KEY
• sudden reuse of n8n-stored credentials against external services
• creation or modification of workflows outside normal admin windows

Example Splunk hunt

splCopy
index=web OR index=app OR index=sysmon
("/form/" OR "n8n")
("{{" OR "process" OR "N8N_ENCRYPTION_KEY" OR "child_process")
| stats count min(_time) as firstSeen max(_time) as lastSeen by host, src_ip, uri, user, process_name, command_line

Strategic takeaway

n8n is widely used as a convenience layer between business systems, internal apps, and third-party SaaS platforms. That convenience also concentrates trust. When critical flaws hit a workflow engine, the impact is not limited to one app server — it can extend into the entire automation fabric around identity, data movement, and secrets.

For mature defenders, this means n8n should be governed like a high-value integration platform, not just a low-risk internal tool. Patch discipline, secrets rotation, permission hardening, and incident response planning all need to reflect that reality.

What is the most dangerous n8n bug in this disclosure?

The two headline issues are CVE-2026-27577 and CVE-2026-27493. The biggest risk comes from chaining unauthenticated expression evaluation in Form nodes with the sandbox-escape flaw to gain remote code execution.

Can attackers steal stored n8n credentials?

Yes, that is one of the most serious risks described by the researchers. If attackers can execute code and access N8N_ENCRYPTION_KEY, they may be able to decrypt secrets stored in the platform.

Are cloud deployments affected too?

Public reporting says both self-hosted and cloud deployments are affected, so teams should not assume managed hosting alone removes exposure.

What should defenders do first?

Patch immediately, restrict workflow-edit permissions, review public Form nodes, and rotate credentials if compromise is suspected.

References

1. The Hacker News, “Critical n8n Flaws Allow Remote Code Execution and Exposure of Stored Credentials,” March 12, 2026.
2. GitHub Security Advisory, GHSA-vpcf-gvg4-6qwr / CVE-2026-27577.
3. GitHub Security Advisory, GHSA-75g8-rv7v-32f7 / CVE-2026-27493.
4. Pillar Security, “Zero-click unauthenticated RCE in n8n: a contact form that executes shell commands.”
5. n8n security advisories for CVE-2026-27495 and CVE-2026-27497.

---

Published: 2026-03-12 Author: Invaders Cybersecurity Classification: Public / TLP:CLEAR Reading Time: 5 minutes