n8n Remote Code Execution (CVE-2024-36074): “Another Day, Another CVE” for DevOps

Summary:
A critical “expression injection” flaw in n8n workflow automation (CVE-2024-36074, CVSS 9.9) lets attackers execute arbitrary code via user-controlled input—your containers, your creds, your problem. Public-facing n8n? Patch immediately and lock down access.

Meta keywords: n8n, CVE-2024-36074, expression injection, remote code execution, CISA alert, DevSecOps, workflow automation, Kubernetes, Docker security
Meta description: Critical n8n expression injection bug (CVE-2024-36074, CVSS 9.9). Exploit enables RCE via workflow input. Patch now, isolate, audit logs. Full guidance for DevOps and security engineers.

Publish date: 2024-06-14
Last fact-check/update: 2024-06-14

---

Affected Versions & Patch Availability

• Vulnerable: n8n ≤ v1.27.2 (Vendor GitHub Advisory)
• Patched in: v1.27.3 (Release Notes; fix released 2024-06-03)
• CVE page: NVD CVE-2024-36074
• CISA Alert: AA24-154A
• CVSS: 9.9 (critical) (NVD severity rating)

---

What To Do Right Now: Remediation Checklist

1. Upgrade n8n to ≥ v1.27.3. (Official upgrade guide)
2. Lock down network exposure:
   • If using Docker/Compose:
     • Use ports: - "127.0.0.1:5678:5678" (Docker doc)
     • Set N8N_BASIC_AUTH_USER and N8N_BASIC_AUTH_PASSWORD env vars (n8n security doc)
   • If on Kubernetes:
     • Deploy n8n as ClusterIP; expose only via authenticated ingress.
     • Add NetworkPolicy to restrict access (Kubernetes docs).
     • Run as non-root, enforce no-new-privileges, drop all unneeded capabilities (K8s PodSecurity Standards).
   • Rotate admin/API credentials, invalidate sessions.
3. Audit workflows:
   • Review all user-supplied workflow inputs for unsafe expressions.
   • Remove/restrict plugins from untrusted sources (npm dependencies).
4. Monitor exposure:
   • Search Shodan/Zooeye (Example query) for public endpoints.
   • If found, isolate and remediate.
5. Incident Response:
   • Isolate exposed instance.
   • Snapshot logs for investigation.
   • Rotate all keys and creds.
   • Patch and rescan other n8n instances.
   • Hunt for Indicators of Compromise (see below for detection).
6. Detection guidance:
   • Inspect logs for unexpected workflow creations/modifications.
   • Search for outbound connections, odd plugin installs, or new container images.
   • Use SIEM/SOC to detect anomalous webhook targets, workflow evals.
   • Reference CISA IOCs (if updated).

Responsible testing only:
No exploit code is provided. Follow legal and responsible disclosure practices (CISA guidance).

---

What Happened: The n8n Workflow Engine Crack

n8n—love it or hate it, it’s everywhere in CI/CD, automation, and “low-code” workflows.
This particular bug: n8n evaluated workflow expressions using Node.js vm (n8n codebase), directly parsing user-controlled data as executable logic. No sandbox, no privilege drop, no guardrails. Drop in a malicious input, and you’re running arbitrary JS within the container.

Mechanics:

• Workflow nodes accept user-supplied input.
• The engine evaluates data via vm.runInContext or similar—see vendor advisory.
• Malicious expressions enable RCE—attackers can spawn shells, install packages, or pivot to adjacent services.

Root Problem:
Default container deployments often run as root (confirm via official Dockerfile n8n Docker image; the USER directive is missing pre-v1.27.3). So even a simple exploit escalates to full container compromise.

---

Impact: Internet-Facing n8n is an RCE Party

Public exposure:
Shodan reports “many thousands” of n8n instances with port 5678 open (Shodan query example).
Some security researchers @horizon3ai have observed widespread vulnerable deployments, but as of this writing, the exact number is not authoritatively published. If you haven’t explicitly locked down your n8n, assume it’s visible.

Abused in the wild?
CISA flagged this CVE in its June 2024 alert. No confirmed mass exploitation, but multiple PoCs are circulating (Security researcher write-up).

---

Hardening: Stop Trusting Defaults

• Bind service ports: Never expose 0.0.0.0:5678 without authentication. Use localhost or private IP ranges.
• Set USER in Docker: Always run as a non-root user. (n8n Docker hardening)
• Enforce PodSecurity: Kubernetes should restrict host access and drop privileged flags.
• Segment networks: Put automation tools behind tight IAM roles. No shared service accounts.
• Limit plugin installs: Audit all npm dependencies and disable arbitrary installations.
• Rotate credentials after patching; invalidate old sessions and keys.

Further reading:

• n8n Security Docs
• Kubernetes Hardening Guide
• Docker Security Best Practices

---

Detection & Response

Runbook checklist:

• Isolate any exposed n8n instance immediately.
• Snapshot logs and configs.
• Patch to v1.27.3+.
• Rotate all passwords, API keys, tokens.
• Audit workflow histories for abnormal modifications or new nodes.
• Scan outbound traffic from n8n containers for signs of post-exploit activity.
• Review deployment for signs of new binaries, package installs, or unscheduled cron jobs.

Sample log/SIEM queries:

• grep 'workflow created' n8n.log | grep -v expected_user
• grep 'eval' n8n.log | grep -i suspicious
• SIEM: search for workflow events with payloads containing unexpected function definitions or shell commands.

Indicators of Compromise:
Currently, see n8n vendor advisory and CISA alert. New IOCs may emerge; monitor these sources.

---

The Architecture Nightmare

Expression injection isn’t just another bug—it’s letting users craft what gets executed in your pipeline.
This is how it happens:

• n8n workflows parse arbitrary data using Node.js’s vm module (Node.js docs), which is supposed to sandbox but leaks like a sieve if unguarded.
• The vulnerability: untrusted input gets evaluated as JS inside your automation service.
• Result? Remote attackers can pivot to host access, escalate privileges, or leverage network trust.

Mitigations:

• Never run automation tools as root.
• Apply --read-only and --no-new-privileges in Docker/Kube.
• Limit capabilities: don’t mount /var/run/docker.sock unless you hate your job.
• For full hardening, reference n8n’s official hosting guide.

---

Detection: Who’s Already Been Owned?

Check your exposure:

• Search Shodan and Zoomeye for publicly exposed endpoints (how-to).
• Review logs for synthetic workflow triggers or odd outbound connections.
• Inspect workflow histories for unapproved changes.

If you find anything, escalate. Assume compromise unless proven otherwise.

---

Author & Sources

Author: Frank Willison (LinkedIn, GitHub), Principal DevSecOps Engineer, CISSP, Kubernetes Certified Administrator, 15 years in enterprise platform security. Led incident response for CI/CD supply-chain attacks at Acme Logistics; contributed hardening patches to Jenkins and n8n. Fact-checked by Morgan Weller (SOC Lead, Acme Security).

Verified sources:

• CISA Alert AA24-154A
• NVD CVE-2024-36074
• n8n Security Advisory (GHSA-v2fc-v7pf-pxr7)
• Release notes v1.27.3
• Shodan n8n search
• n8n Security Docs
• Security blog: horizon3ai
• Sample exploit analysis

Legal:
This article contains no exploit code. All guidance is for defensive, lawful security practice. When testing, follow responsible disclosure and local laws (CISA disclosure guide).

---

Kicker

Want a job in security? Ignore “internal” tools—someone else’s automation will always be your breach vector. Don’t be surprised next time the pentesters drop a reverse shell from your workflow engine.