CISA warns max-severity n8n bug is being exploited in the wild

There are yet more vulnerabilities in n8n.

If that name sounds familiar, it’s because I feel like I’ve covered n8n security issues at least once or twice a month recently. It seems to be a pretty ripe target for vulnerability research right now.

Makes sense when you think about what the software actually does.

If you’re not familiar with n8n, it’s basically an open-source automation platform. Think something like Zapier or IFTTT — those “if this happens, then do this” workflow tools. Except n8n is open source and increasingly used for AI-driven automation pipelines.

You use it to build workflows using a visual interface. When something happens — a webhook triggers, a message arrives, a file gets uploaded — the platform can run a sequence of actions.

Maybe it queries an API, or calls an AI model, or pushes something into Slack or a database. You drag blocks onto a flowchart and connect them together.

So when a chat message arrives, maybe the system calls an OpenAI API, looks up data somewhere, queries a search engine, writes something to a database, and then posts the result to Slack.

All those integrations require credentials, which means people are loading their n8n servers with API keys and authentication tokens for all sorts of services:

• Slack

• Google Drive

• Telegram

• HubSpot

• databases

• internal webhooks

• cloud services

When you compromise an n8n server, you’re not just compromising one application, but potentially an entire credential hub for a company’s automation stack. That’s why vulnerabilities in this software are so attractive to attackers.

The vulnerability that triggered the latest alerts allows attackers to bypass sandbox protections and execute malicious payloads that lead to remote code execution.

CISA warned that the bug is being actively exploited in the wild. When something lands on the “known exploited vulnerabilities” list, that means attackers are already using it. Once you combine remote code execution with a system full of stored credentials, things can get ugly pretty quickly.

If an attacker gets access to the n8n database, they can potentially extract all the API keys stored inside the platform, which means they could then start accessing other services directly to read company email, access internal databases, send messages as the organization or trigger additional automation workflows. It’s a credential jackpot.

Many n8n deployments are designed to be accessible from the internet. The whole point of automation tools like this is that they interact with external services to receive webhooks, talk to APIs and trigger actions across different platforms.

So it’s not always realistic to lock these systems down behind extremely strict firewall rules.

That means if you’re running an exposed instance and haven’t patched it yet, attackers may already be probing it.

Another wrinkle is that the vulnerability being actively exploited isn’t even the only one affecting the platform right now. Researchers have identified multiple issues in n8n recently, including flaws that allow attackers to escape sandbox restrictions and execute arbitrary code.

Some of these vulnerabilities involve the way expressions and workflow logic are evaluated during configuration and execution. In certain cases, malicious payloads can bypass runtime protections and execute commands before security controls kick in. That means attackers can go from user-level access to full system compromise.

If you’re running n8n anywhere in your environment, now is probably a good time to take a look at it.

Patch it, review access controls and maybe put some guardrails around it, because when your automation platform doubles as a central repository of API keys, compromising that system can quickly turn into a much larger breach.