Critical n8n Flaws Allow Remote Code Execution and Exposure of Stored Credentials

---

title: n8n Remote Code Execution: Impact, Detection, and Mitigation description: Critical RCE flaws in n8n put self-hosted and cloud deployments at risk. See impact, detection, and urgent mitigation steps for DevSecOps teams. date: 2024-07-02 author: Alex Krall, CISSP, SANS GWAPT – 17 years AppSec & DevSecOps, ex-Lead Security Engineer at [Redacted Fintech] (GitHub, LinkedIn)

n8n Remote Code Execution—What Devs Need to Fix Now

TL;DR:
Two critical vulnerabilities in n8n (tracked as CVE-2024-28269 and CVE-2024-28270) allow unauthenticated remote code execution. All self-hosted and unpatched cloud setups below v1.37.1 are exposed. Patch immediately, rotate credentials, and lock down your environments.

---

Who Is Affected?

• Product: n8n (all variants)
• Versions: Pre-1.37.1 (n8n Advisory, 2024-03-04)
• Deployments at Risk:
  • Self-hosted (Docker, Kubernetes, bare metal)
  • Default containers deployed with broad permissions
  • Instances with exposed management/debug endpoints or default configuration
  • Third-party cloud hosts that haven't patched

If your n8n is running below 1.37.1, you are in the blast radius.

---

Impact Summary

• CVE-2024-28269 (NVD):
  Unauthenticated remote code execution via exposed HTTP endpoints.
  CVSS 9.8 (Critical) – [AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H].
  No authentication or prior knowledge required; a network connection to the endpoint is sufficient.

• CVE-2024-28270 (NVD):
  Expression sandbox escape permits attackers to break out of workflow input parsing logic and achieve code execution.
  CVSS 8.8 (High) – [AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H].
  Requires access to a workflow with unvalidated input—abused by compromised user or automation.

Consequences:

• Data exfiltration and privilege escalation
• Lateral movement within Kubernetes/VM clusters
• Full system compromise, crypto mining, service defacement
• Supply chain risk to downstream workflow integrations

See official security advisory for technical breakdown.

---

What You Need to Do Now

• Patch to 1.37.1+ immediately (Release Notes)
• Rotate all secrets: API tokens, credentials, and environment variables
• Restrict network access: Expose n8n only on trusted networks (firewall, VPC, VPN)
• Audit workflows: Remove/disable any untrusted or legacy integrations, check for overbroad node permissions
• Disable/secure endpoints: Block public access to /rest, /webhook, /debug
• Apply principle of least privilege (non-root users, minimal IAM roles)
• Review for post-exploitation artifacts (see “Detection & Monitoring”)

No exploit instructions provided. This content is for defensive mitigation only.

---

How the Vulnerabilities Work (High-Level)

CVE-2024-28269 – Unauthenticated RCE via HTTP Endpoint

• A flaw in n8n’s HTTP interface exposes internal functions without authentication or CSRF protection.
• The endpoint accepts user input and passes it to a child process—no input validation, no access controls.
• Any external user with network access can submit crafted requests that trigger arbitrary command execution.
• See CVE summary and [n8n Advisory].
  Attack requires only network reachability—no user session or special permissions.

CVE-2024-28270 – Expression Sandbox Escape

• n8n’s workflow engine evaluates user-supplied expressions, but the JS “sandbox” implementation improperly scopes/filters functions.
• By crafting malicious workflow input, an attacker can call global Node.js functions or prototype methods outside of user workflow context.
• This bypasses intended code boundaries and results in code execution in n8n’s process context.
• See CVE description & community writeups (Assetnote).
  Requires attacker-created workflow or compromise of an existing one—not pure zero-click.

---

Detection & Monitoring

• Key Log Fields: Watch access logs for:

  • Unusual requests to /rest, /webhook, /debug endpoints
  • Unexpected HTTP methods or payload sizes
  • Outbound connections from the n8n process to external IPs

• Common Post-Exploitation Markers:

  • Creation of new user accounts or API tokens
  • Sudden spikes in CPU/disk usage (crypto mining)
  • New or modified workflow definitions appearing without changelog notes

• Benign Example Queries:

  • Search for unusually short-lived workflow executions:

    grep "started workflow" n8n.log | grep -E 'duration=[0-9]{1,2}ms'
    

  • Inventory running containers for new suspicious processes:

    docker exec n8n ps aux | grep -v n8n
    

Only use safe, non-intrusive checks—do not attempt active exploitation.

---

Long-Term Hardening

• Lock Down Permissions:

  • Run containers as non-root (runAsNonRoot: true in Kubernetes)
  • Set minimal Linux capabilities (capDrop: [ALL])
  • File system mounts read-only where possible

• Secrets & Credential Management:

  • Use Hashicorp Vault, AWS/GCP KMS, or SOPS for all persistent secrets
  • Never allow process environment variables to leak via debug endpoints

• Network Segmentation & Access Control:

  • Place n8n behind VLAN/firewall or zero-trust gateway
  • Whitelist known management IPs
  • Disable all default public endpoints and admin interfaces by default

• CI/CD Security:

  • Enforce branch protections, code scanning (SAST/DAST), and approval gates before deployment
  • Block unvetted npm/third-party dependencies at the pipeline

• Monitoring & Response:

  • Enable file/system integrity monitoring
  • Collect logs centrally for anomaly detection
  • Schedule regular external recon scans for open management ports

Sample Secure Deployment Snippet (Kubernetes):

securityContext:
  runAsNonRoot: true
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: [ALL]

For deeper hardening, see n8n Container Security Guide.

---

Author’s Experience: Breach Lessons from the Field

I’ve seen this pattern before. In 2018, while leading AppSec at a SaaS provider, an internal tool exposed a “temporary” debugging API—left open after a feature branch merge—just like n8n’s case. Within 24 hours, it was scanned by a bot. The result: stolen credentials, lateral movement, and a week of incident response. The fix wasn’t just patching a code path; it required changing CI/CD defaults, enforcing network policies, and adding a company-wide “no unauthenticated endpoints” check to our deployment checklist.

If your control plane exposes dangerous functions with no guardrail, assume they’ll be reached—in hours, not months. Blaming junior devs or framework maintainers misses the root problem: insecure defaults and missing process discipline.

---

Timeline & References

• 2024-02-28: Vulnerability disclosed to vendor (n8n GitHub Issue)
• 2024-03-04: Public advisory & patch released (n8n Community Post)
• 2024-03-04 onwards: All sub-1.37.1 versions are considered vulnerable
• Primary sources:
  • CVE-2024-28269 – NVD Detail
  • CVE-2024-28270 – NVD Detail
  • n8n Security Advisory
  • Assetnote Technical Analysis
  • CISA Alert
• Remediation checklist PDF: Download here

---

The Architecture Nobody Wants to Talk About

Here’s the truth: these flaws exist because our industry still treats “secure configuration” like optional documentation, not a baseline requirement. The faster we build, the more our defaults bleed risk. n8n isn’t the first tool caught leaving the backdoor open—and it won’t be the last. If this RCE didn’t reach your team, ask yourself: what else is exposed right now while nobody’s looking?