Critical n8n RCE Flaws: Time to Audit Your Automation Workflows
Hey everyone, just caught the disclosure on n8n. For those using it for workflow automation, you need to pay attention to this immediately. Two critical CVEs dropped that are essentially remote code execution (RCE) and credential theft bugs.
Here is the breakdown:
- CVE-2026-27577 (CVSS 9.4): Expression sandbox escape leading to RCE.
- CVE-2026-27493 (CVSS 9.5): Unauthenticated access to stored credentials.
The core issue is that the "Expression" sandbox in n8n can be escaped. Since these tools are often used to connect to CRMs, databases, and email servers, the risk of credential dumping is massive. An unauthenticated attacker chaining these could theoretically dump your environment variables or execute code to pivot further into your network.
First step: Verify your version.
npx n8n --version
If you are self-hosting via Docker, check the image creation time to see if it is pulling the patched build:
docker images n8nio/n8n --format "table {{.Repository}}\t{{.Tag}}\t{{.CreatedAt}}"
I'm also recommending a quick audit of your logs for any suspicious activity around the "expression" endpoints or unexpected child processes.
grep "error" /var/log/n8n/n8n.log | grep -i "expression" | tail -n 10
Given that automation tools often have high privileges to do their jobs, how is everyone handling the blast radius? Are you running these as non-root users inside containers, or do you just accept the risk and patch fast?
We saw this and immediately pushed an emergency patch via Ansible for our internal instances. The unauthenticated credential exposure (CVE-2026-27493) was the scariest part for us because n8n holds keys to our kingdom.
We are isolating all automation tools in a dedicated VPC with strict egress rules now. If an RCE happens, at least they can't reach the internal DBs directly.
Great writeup. From a pentester perspective, these low-code platforms are goldmines for us. The 'Expression' sandbox is rarely tested properly by devs.
If you are looking for detection logic, watch for n8n node processes spawning unexpected shells. A simple query like this in your SIEM helps:
ProcessCreate
| where FileName in ("bash", "sh", "powershell.exe")
| where ParentProcessName contains "node"
| where ParentProcessCommandLine contains "n8n"
Oof, this is rough. We have a client who uses n8n to bridge their legacy SQL server to a cloud CRM. The n8n instance runs as root on an old Ubuntu box because 'it just works that way'.
Trying to explain to them why we need to containerize it now is going to be a fun meeting. Thanks for the Docker command, that'll help me prove they are outdated.
Don't forget to audit your workflow backups. Sometimes attackers inject malicious workflows that persist even after patching. You can grep your exported JSONs for suspicious process or child_process calls often used in these escapes.
grep -r "child_process" /path/to/n8n/backups/
Nina’s backup check is crucial. Additionally, I recommend querying the runtime database directly for artifacts of the sandbox escape, specifically looking for references to child_process or fs in successful executions. This helps catch active exploitation if you don't have stdout logging enabled.
SELECT id, workflow_id, finished_at
FROM execution_entity
WHERE data::text LIKE '%child_process%'
OR data::text LIKE '%.env%'
ORDER BY finished_at DESC LIMIT 20;
Good point, Dylan. Since n8n often bridges IT and OT environments, this RCE is a serious pivot risk into control networks. Beyond patching, ensure these automation servers are in a DMZ with strict egress rules. You shouldn't allow wildcard access to PLCs or historians.
A quick way to check for unexpected outbound connections on a Linux node is to list established connections:
ss -tnp | grep ESTAB
If you see connections to industrial protocols that aren't documented, you have a bigger problem.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access