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

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: minimise 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 prioritise remediation based on heightened scrutiny and actual exposure, considering which webhooks, nodes, and execution contexts are actively in use.

Remediation Guidance (By Usage)

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.

‍