So after the Apple iOS zero-days landing on CISA’s KEV catalog yesterday this shit is the first news of the morning, Haven’t even washed my coffee cup (I really rarely do) — when CISA dropped another KEV addition that made me slam my espresso cup down hard enough to slosh the thing. n8n. The workflow automation platform. CVE-2025-68613. CVSS 9.9. Actively exploited. And twenty-four thousand seven hundred instances still sitting on the open internet, unpatched, three months after the fix was available. Three months. I want whoever made that patching decision to look me in the eye and explain it to me. I have time.

Let me set the scene because a lot of people in security still think of n8n as “that thing developers use for webhooks.” It is not that. It is a self-hosted automation platform that connects your email, your databases, your cloud services, your APIs, your CRM, your Slack, your payment processor, your HR system, and everything else you run into orchestrated automated workflows. It is, functionally, a master key to every integrated service in your environment. And right now there are 24,700 instances of it hanging off the internet with a 9.9-severity RCE vulnerability that attackers are actively using. Great. This is fine.

What Actually Happened

Per The Hacker News on March 12, 2026, CISA added CVE-2025-68613 to its Known Exploited Vulnerabilities catalog based on confirmed evidence of active exploitation in the wild. The vulnerability carries a CVSS score of 9.9 — that’s as close to the top of the scale as you can get without having a perfect 10 — and it’s an expression injection flaw in n8n’s workflow expression evaluation system that leads to remote code execution.

What that means in plain language: n8n lets users write expressions inside workflows to process data dynamically. The expression evaluation engine wasn’t properly controlling what code could be injected into those expressions. An authenticated attacker — meaning someone who has any kind of access to your n8n instance, including a low-privilege account — could inject malicious expressions that execute arbitrary code with the full privileges of the n8n process. On a self-hosted instance running as root or with elevated service account privileges, that’s a full system compromise through one crafted payload.

n8n patched this in December 2025 in versions 1.120.4, 1.121.1, and 1.122.0. That is not this week. That is not last week. That is three months ago. And according to internet exposure scans, 24,700 instances are still running vulnerable versions. CISA added it to the KEV because people aren’t patching, attackers noticed, and now it’s an active exploitation campaign.

And here’s where the week gets worse. The same day CISA dropped the KEV addition, The Hacker News also published details of two additional n8n vulnerabilities disclosed by Pillar Security on March 11, 2026: CVE-2026-27577 (CVSS 9.4), a sandbox escape in the expression compiler where a missing case in the AST rewriter lets the process object slip through untransformed — handing any authenticated expression full RCE — and CVE-2026-27493 (CVSS 9.5), an unauthenticated expression evaluation flaw via n8n’s Form nodes that allows expression injection without any authentication at all. That second one. Let that land. Unauthenticated. Anyone who can reach your n8n Form endpoint can inject code. Zero credentials required. These were patched in more recent versions, but they compound the urgency: if you have a vulnerable n8n instance, you now have three separate CVEs to contend with, two of which score above 9 and one of which requires no login whatsoever.

Why This Is Not a Developer Problem — It’s an Enterprise Disaster

I know what happens when a workflow automation tool hits the security news. The security team goes “oh that’s a developer tool, not our problem.” The developers go “we’ll get to it.” And the 24,700 exposed instances remain exposed while both groups argue about whose queue it belongs in.

So let me explain precisely why n8n RCE is your problem regardless of what department owns it.

n8n workflows hold credentials. That’s not a metaphor. The platform stores the API keys, OAuth tokens, database connection strings, SMTP credentials, and service account passwords used by every workflow it runs. When you integrate n8n with your CRM, you give n8n a credential for the CRM. When you integrate it with your cloud storage, it holds a storage access key. When you integrate it with your email, it has SMTP auth. If an attacker achieves RCE on your n8n instance, they don’t just control n8n. They extract every credential stored in n8n’s configuration and workflow data, and now they have authenticated access to every integrated system simultaneously.

Think about what that means for a typical automation-heavy environment: Slack tokens, Google Workspace service accounts, database credentials, Stripe or PayPal API keys, HR system integrations, internal tool APIs, and whatever else the engineering team connected over the past two years. One RCE on n8n, and the attacker is walking through every connected service with valid credentials that won’t trigger login anomaly detections because they’re authenticated sessions from known service accounts.

As I covered in the Clop Oracle EBS campaign against third-party vendors including MSG, the pattern is consistent and deliberate: attackers target the platforms that touch everything because one breach multiplies into every downstream integration. n8n is exactly that kind of platform. It is not a standalone tool. It is a nerve center. Compromise the nerve center, own the network.

The automation tool category as a whole sits in a dangerous blind spot: dev teams deploy these tools quickly, often outside the normal IT procurement and security review process, with elevated service account permissions and external network exposure configured for webhook ingestion. They’re then left running, unmonitored, with credentials that were generated when the tool was set up and never rotated. The only time anyone looks at them is when something breaks. That is not a security posture. That is a disaster waiting for a CISA KEV notification to make it official.

What Went Wrong — Expression Evaluation Is Always the Problem

Let me rant about this for a minute because I’m tired of seeing the same architectural mistake recycle through every generation of developer tooling.

Expression evaluation systems — the things that let users write {{ $json.fieldName }} or mathematical operations or string manipulations inside a workflow — are notoriously difficult to sandbox safely. You’re essentially building a small programming language interpreter inside your application and then handing it to users to write arbitrary code. Doing this safely requires strict Abstract Syntax Tree (AST) validation that blocks any expression that could reference dangerous runtime objects. CVE-2026-27577 is an AST rewriter with a missing case — one code path that the sanitizer doesn’t handle, which lets process (Node.js’s global process object, giving access to environment variables, spawn, and everything else) pass through unmodified. One missing case in the sanitizer. Three months of unpatched exposure. Twenty-four thousand seven hundred vulnerable instances.

The unauthenticated variant, CVE-2026-27493, is arguably worse from an architecture standpoint because it means the Form node endpoints were running expression evaluation on user-supplied input without requiring authentication. That’s not a subtle bug. That’s a design decision that put expression evaluation on a public-facing endpoint without considering what an adversary could do with it.

As I’ve documented in my research on why a Cyber 9/11 remains a realistic near-term scenario, the highest-consequence incidents occur when widely deployed infrastructure tools have critical vulnerabilities that are slow to patch. Automation platforms running inside enterprise environments with broad integration permissions are exactly the kind of infrastructure where a single exploited instance can cascade into a systemic breach. n8n running in a medium-sized company’s environment, connected to 30 different business services, is a Cyber 9/11 in miniature waiting to happen.

The Fixer’s Advice — Here’s What You Do Right Now

No prioritization matrix. No “assess your risk.” You patch this now. But let me give you the full remediation sequence because there are things to do beyond updating the version number.

1. Patch to n8n 1.122.0 or later immediately. This is not a “schedule for next sprint” item. This is a CISA KEV addition with confirmed active exploitation. Federal agencies have binding remediation deadlines. You should treat it the same way. If you can’t patch in the next 24 hours because of change management process, get your security team to block external access to the n8n instance until the patch is applied.

2. If you can’t patch immediately, restrict network access first. n8n should not be listening on a public IP address with a public port under any normal operating condition. If yours is, close that exposure at the firewall right now. n8n should be accessible only through a VPN or internal network, or behind an authenticated reverse proxy with strict IP allowlisting. This is true after you patch too — public internet exposure of workflow automation tools is a bad practice regardless of patch status. As I covered in my post on VMware Aria Operations getting KEV-listed for admin console exposure, admin and management interfaces should never be on the public internet. Automation platforms are management interfaces.

3. Audit and rotate every credential stored in n8n. Pull the full list of integrations. Every API key, OAuth token, database credential, and service account password used in any workflow. Rotate all of them. Yes, all of them. Yes, even the ones that “probably weren’t affected.” You’re doing this because if your instance was compromised before you patched, the attacker has those credentials. Rotating them ends the session. Skipping this step because it’s annoying leaves a persistent access path alive after you think you’re clean.

4. Check your n8n logs for indicators of exploitation. Look for unexpected workflow executions, expressions that reference process or child_process, unexpected outbound network connections from the n8n process, and any new user accounts or credential additions in the platform. If you don’t have n8n logs flowing into your SIEM, fix that as part of this incident response.

5. Check for persistence mechanisms. If an attacker achieved RCE on your n8n instance, they may have established persistence — a cron job, a new workflow that executes on a schedule, modifications to n8n’s configuration files, or a reverse shell process. After patching, audit running processes, scheduled tasks, and n8n’s workflow list for anything you didn’t create.

6. Verify n8n is running with least-privilege service account permissions. n8n should not run as root or as a domain administrator. It should run as a dedicated service account with permissions limited to exactly what it needs to execute its configured integrations and nothing else. File system access, network access, and system call privileges should all be restricted. If yours is running as root because “that’s how it was set up,” fix that now.

7. Implement MFA for n8n access. The authenticated variant (CVE-2025-68613 and CVE-2026-27577) requires attacker authentication. Strong authentication and MFA for n8n access raises the bar significantly. This doesn’t replace patching — CVE-2026-27493 is unauthenticated — but it’s a baseline security control that should be in place for any automation platform regardless.

The 24,700 exposed instances are not all running in abandoned dev environments. Some of them are production automation infrastructure at real organizations, connecting real business systems, holding real credentials. The attacker who figured out how to exploit CVE-2025-68613 knew exactly what they were getting into when they targeted those instances. They weren’t after n8n. They were after what n8n could touch.

Go patch. Then rotate every damn credential in the thing.