The n8n Nightmare: Exploiting CVE-2026-21858

Automation is supposed to save time, reduce mistakes, and make teams look far more organized than they really are. Then a critical vulnerability shows up and reminds everyone that giving one platform access to files, workflows, secrets, and integrations was definitely a bold lifestyle choice.

That is exactly why CVE-2026-21858 got so much attention. It hit n8n, a workflow automation platform widely used in self-hosted environments, and exposed a scenario where an unauthenticated attacker could abuse certain form-based workflows to access files on the underlying server. The issue affects n8n versions 1.65.0 through 1.120.4 and was fixed in 1.121.0. Public advisories classify it as Critical, with a CVSS 10.0 score.

What is n8n?

n8n is an automation platform that connects services, processes data, moves files, and runs workflows across business systems. In many environments, it also sits close to sensitive assets like API keys, database connections, internal services, file storage, webhooks, and AI-driven workflows. That makes it incredibly useful and, from an attacker’s perspective, incredibly interesting.

When a tool like that becomes vulnerable, the problem is not just “one app has a bug.” The real problem is that automation platforms often become trust hubs. They can read, send, trigger, authenticate, and orchestrate. So if one exposed workflow can be abused without authentication, the blast radius can grow very fast.

What is CVE-2026-21858?

According to the official advisory, CVE-2026-21858 allows access to files on the underlying server through the execution of certain form-based workflows. In practice, this means a specially exposed workflow can give an unauthenticated remote attacker a path to sensitive file access, depending on how that workflow is configured and what the host stores locally. The vendor advisory and the NVD both describe the issue as potentially leading to exposure of sensitive information and further compromise.

The important detail here is that not every n8n instance was exposed in the same way. The vendor states that the vulnerable scenario requires an active workflow with both of the following:

• a Form Submission trigger
• a Form Ending node returning a binary file

That condition matters because it helps explain why this bug was so interesting technically. It was not just “n8n is vulnerable” in the abstract. It was “specific workflow logic can turn a public form endpoint into a dangerous primitive.”

Why the hype?

Because this is the kind of vulnerability that checks every box security people love to hate:

• no authentication required
• internet-reachable workflows
• access to underlying server files
• possible exposure of secrets and internal data
• potential chaining into deeper compromise

And once a workflow engine is involved, the conversation gets bigger than one bug. Workflow platforms are designed to be central. They sit between users, APIs, storage, notifications, credentials, and business logic. So even when the initial primitive is “file access,” the follow-on impact may include configuration disclosure, secret leakage, workflow intelligence, and privilege expansion depending on the environment. That is exactly why this issue got so much visibility.

Explaining the vulnerability

A good way to explain CVE-2026-21858 without drowning the reader in implementation details is this:

1. A public form endpoint is exposed.
2. A vulnerable workflow handles that form in an unsafe way.
3. Improper input handling lets the attacker influence how content is processed.
4. The workflow returns data that should never be retrievable by an unauthenticated user.
5. Sensitive files become accessible, opening the door to broader compromise.

That framing is simple, technically faithful, and easy for readers outside AppSec to understand.

Why is this dangerous?

The danger is not only the bug itself. It is where the bug lives.

In many self-hosted deployments, n8n may have access to environment variables, local application files, workflow data, tokens, and service credentials. Even when the platform is not directly holding production crown jewels, it often acts as a bridge to systems that do. So a vulnerability that starts with file access can quickly become an investigation into what else that host can reach, what credentials are stored nearby, and what automations can be abused next.

This is also why automation security deserves more attention than it usually gets. People love talking about AI agents, low-code power, and workflow acceleration. Much less attention is given to how these platforms quietly become infrastructure.

PoC

For this PoC, we will use the exploit available in this repository. Credits to Chocapikk.

We then launched the vulnerable version of n8n (1.65.0), created the vulnerable form workflow, and ran the exploit:

Behind the scenes, the exploit abused a vulnerable public n8n form workflow to trigger its file-handling logic with a crafted request. Because of improper request parsing, the application treated attacker-controlled input as valid file-related data and returned the contents of a local server file in the response. In this PoC, the result was unauthorized file read, which is why /etc/passwd could be retrieved without authentication.

Who was affected?

The vendor advisory states that the vulnerable population was primarily self-hosted instances running versions 1.65 to 1.120.4 under the affected workflow conditions. It also states that:

• 1.121.0 or later is not affected
• 2.x versions already contain the fix
• cloud customers had already been upgraded and secured by the vendor

That distinction is useful in the article because it helps separate “product-wide panic” from the actual exposure conditions.

Mitigation and defensive takeaways

The most important mitigation is simple: upgrade to n8n 1.121.0 or later. Both the GitHub advisory and the vendor community advisory point to that as the fix. The GitHub advisory also notes that there are no official workarounds, although temporarily restricting or disabling publicly accessible webhook and form endpoints can reduce exposure until patching is complete.

From a defensive standpoint, this case also reinforces a few broader lessons:

• public workflow endpoints deserve the same scrutiny as custom application routes
• automation platforms should not be treated as “just internal tools”
• secrets and local files on workflow hosts increase the impact of seemingly narrow bugs
• internet-exposed form and webhook features should be inventory-controlled and regularly reviewed

In other words, if a platform can orchestrate your business, it can also accelerate your incident response timeline in the worst possible way.

Conclusion

CVE-2026-21858 is a great example of why automation security matters more than many teams assume. The vulnerability was not interesting just because it was critical. It was interesting because it lived inside a platform designed to connect everything to everything else, which is usually a fantastic idea right up until it very much is not.

And that is the charm of modern automation: one minute it is saving hours of manual work, the next it is starring in a post-incident timeline nobody wanted to write.