Understanding Recent n8n Vulnerabilities: Exposure, Risk, and Remediation

In recent weeks, six critical and high-severity vulnerabilities have been disclosed in n8n, affecting webhook handling, expression evaluation, code execution nodes, and integrations like Stripe Trigger. When multiple issues affect different components, the focus shifts from individual bugs to cumulative exposure and how that exposure maps to real-world deployments.

This post helps teams understand that collective exposure and provides targeted guidance on remediation decisions.

The Vulnerabilities

CVE	Severity	Access Required	Component	Impact	Fixed In
CVE-2026-21858	Critical (10.0) - Public PoC	Unauthenticated	Webhook parsing	RCE via content-type confusion	1.121.0+
CVE-2026-21877	Critical (10.0) - Public PoC	Authenticated (workflow editor)	Git node	File write → RCE	1.121.3+
CVE-2025-68613	Critical (9.9) - Public PoC	Authenticated (workflow editor)	Expression engine	Expression injection → RCE	1.120.4, 1.121.1+
CVE-2025-68668	Critical (9.9)	Authenticated (workflow editor)	Python Code Node	Sandbox bypass	2.0.0+
CVE-2025-68697	High (7.1)	Authenticated (workflow editor)	Legacy JS Code Node	Filesystem access	2.0.0+
CVE-2026-21894	Medium (6.5)	Unauthenticated	Stripe Trigger	Forged webhooks	2.2.2+

Context

n8n is a highly flexible automation platform: it accepts external webhooks, evaluates user-defined expressions, integrates deeply with third-party services, and allows workflows to execute custom code. Each capability expands the attack surface by design.

Two patterns stand out:

• Dynamic execution paths: Several CVEs target the expression engine and Code nodes (Python and legacy JavaScript). Allowing workflow authors to execute custom code or expressions is powerful, but difficult to isolate safely. The issues here reflect common containment challenges seen across automation and CI/CD platforms, not challenges unique to n8n. Recent changes, like task-runner-based execution, signal a deliberate shift toward stronger architectural isolation.
• Externally triggered workflows: Other issues relate to webhook and integration handling (e.g., form/webhook parsing and Stripe Trigger). These vulnerabilities stem from the complexity of safely ingesting untrusted external inputs and validating third-party events. Platforms that expose public triggers and deep integrations face similar risks.

In practical terms, n8n should be treated as critical execution infrastructure: minimize exposure, restrict who can author workflows, and keep pace with architectural hardening as the platform evolves.

Understanding Your Risk Exposure

Risk varies significantly based on your deployment model and access controls:

Highest Risk:

• Public-facing n8n instances with form/webhook endpoints (CVE-2026-21858 - unauthenticated exploitation)
• Self-hosted with external user access or weak authentication

Moderate Risk (with access controls):

• Internal-only deployments where workflow editing is restricted to trusted administrators
• 5 of 6 CVEs require authenticated access with workflow editing permissions
• Strong access controls significantly reduce attack surface

Key Mitigation Factor: Limiting workflow creation/editing to a small group of fully trusted users materially reduces risk for CVE-2026-21877, CVE-2025-68613, CVE-2025-68668, and CVE-2025-68697.

The Impact of Aggregated Security Findings on Risk Posture

Not every vulnerability starts with a public proof-of-concept. But when multiple issues emerge across a product’s major components, they draw sustained attention from both defenders and attackers. This often leads to additional findings or exploit techniques surfacing over time.

Teams should prioritize remediation based on heightened scrutiny and actual exposure, considering which webhooks, nodes, and execution contexts are actively in use.

Remediation Guidance (By Usage)

Your Deployment	Target Version	Reasoning
Public-facing instances with webhooks/forms	1.121.0+ immediately	CVE-2026-21858 requires no authentication; critical priority regardless of access controls
Most n8n 1.x deployments (standard webhooks, integrations, no dynamic code execution)	1.121.3+	Addresses core critical issues on the 1.x line (CVE-2026-21858, CVE-2026-21877, CVE-2025-68613)
On v1.121.0-1.121.2 and don’t use Git node	1.121.0+ with Git node disabled	Disable Git node via NODES_EXCLUDE: ["n8n-nodes-base.git"] to mitigate CVE-2026-21877; upgrade to 1.121.3+ when feasible
Still on v1.120.x	1.120.4 → then 1.121.3+	1.120.4 remediates critical expression evaluation (CVE-2025-68613); treat as transitional
Using Python Code Node	2.0.0+	Addresses Python sandbox bypass (CVE-2025-68668) via task runner-based execution model
Using legacy JavaScript Code Node (task runners disabled)	2.0.0+ or enable task runners on v1.71.0+	Addresses filesystem access vulnerability (CVE-2025-68697); task runners provide stronger isolation
Using Stripe Trigger node	2.2.2+	Patches webhook signature verification gap (CVE-2026-21894)

Immediate Risk Reduction Through Access Controls

Before or during patching, restrict access:

1. Audit workflow editing permissions - Limit to trusted administrators only
2. Review user roles - Remove workflow editing from unnecessary accounts
3. Implement MFA - Strengthen authentication for all workflow editors
4. Network segmentation - Restrict n8n access to internal networks where possible
5. Monitor workflow changes - Alert on new/modified workflows

Note: Access restrictions do NOT mitigate CVE-2026-21858 (unauthenticated RCE) - patching is essential.

Mitigation Without Immediate Upgrade

If upgrade isn’t immediately feasible:

CVE-2026-21877 (Git node):

• Disable via NODES_EXCLUDE: ["n8n-nodes-base.git"] if not required

CVE-2026-21858 (Webhooks):

• No workaround. Upgrade to 1.121.0+ required
• Restrict public endpoints if delayed

CVE-2025-68668 (Python Code Node):

• Disable Python: N8N_PYTHON_ENABLED=false (v1.104.0+)
• Or disable entire Code node: NODES_EXCLUDE: ["n8n-nodes-base.code"]

CVE-2025-68697 (Legacy JS Code Node):

• Best: Enable task runners via N8N_RUNNERS_ENABLED=true (v1.71.0+)
• Alternative: Restrict file access via N8N_RESTRICT_FILE_ACCESS_TO=~/.n8n-files + keep N8N_BLOCK_FILE_ACCESS_TO_N8N_FILES=true
• If editors untrusted: Disable Code node via NODES_EXCLUDE: ["n8n-nodes-base.code"]

Immediate Actions:

1. Audit current n8n version and enabled nodes
2. Review who has workflow editing permissions
3. Identify which features you actively use (webhooks, Git node, Code nodes, Stripe integration)
4. Select target version based on usage or apply mitigations
5. Review publicly accessible endpoints
6. Monitor github.com/n8n-io/n8n/security for updates

Practical Takeaway

With public proof-of-concepts available for three critical vulnerabilities and ongoing security research, teams should treat n8n as critical infrastructure and respond accordingly.

‍