CVE-2026-21858

n8n is like an automation “mailroom” that receives requests and triggers workflows. In this issue, someone can send a specially crafted webhook request and, without logging in, cause n8n to disclose files that live on the server—like a backstage folder full of sensitive documents. If those files include secrets (API keys, tokens, or config), an attacker may be able to do more than just view data.

This matters if you run n8n on a server that’s reachable from the internet, because the problem is usable without any login. It specifically depends on whether certain webhook-handling workflows/endpoints are reachable and can be triggered by attackers. If n8n is not exposed to untrusted networks or relevant webhook endpoints are not reachable, the risk is lower—but exposure status is not yet known from the findings.

This is RED because attackers are actively probing for this kind of weakness, and the reported activity includes automated scanning attempts. Even without confirmed real-world successful exploitation in dated reporting, the vulnerability is unauthenticated and directly enables reading server files, which makes rapid patching the right move.

Confirm exposure:

• Identify the n8n version currently installed.
• Determine whether n8n is reachable from untrusted networks (for example, public internet exposure) and whether any webhook endpoints/workflows are enabled.

Check for vulnerability:

• If your n8n version is earlier than 1.121.0, you should assume it’s affected.
• Pay special attention to workflows that accept webhook-style inputs and could be triggered remotely.

Upgrade to the fixed version:

• Upgrade n8n to 1.121.0 or newer using the official upgrade path.
• Use the vendor’s security advisory as the source of truth for upgrade steps: https://github.com/n8n-io/n8n/security/advisories/GHSA-v4pr-fm98-w9pg

Post-upgrade hardening:

• Disable any webhook endpoints/workflows that you don’t need.
• Restrict access to any remaining webhook endpoints so only trusted callers can reach them (network-level controls and/or application-level access controls where applicable).

Validate:

• After upgrading, confirm the service restarts cleanly and that expected workflows still run.

Temporary workaround if you cannot patch immediately:

• Block network access to n8n from the internet until you can patch (for example, restrict by firewall/reverse proxy rules to only trusted IPs). This reduces the chance of unauthenticated probing reaching the vulnerable webhook paths.

What to monitor:

• Look for repeated, automated webhook requests that do not resemble normal workflow traffic.
• Review logs around webhook endpoints for unexpected request paths or parameters associated with file-access attempts.

Severity is critical in practice because the issue is unauthenticated (no login required) and enables reading arbitrary files from the server’s file system, which can expose secrets and enable further compromise. The underlying weakness is Improper handling of webhook requests (CWE-20), and exploitation targets certain workflows where webhook-triggered request handling can be abused for file reads.

Exploitation status: there is no KEV entry and no clearly dated, confirmed real-world exploitation claim in the findings; however, public Proof-of-Concept code exists and there has been sustained press/interest and automated scanning attempts by named actors (knaithe, KnYuan). The traffic light verdict is still RED because the vulnerability is directly reachable over the network without authentication.

Fix guidance: n8n is fixed in version 1.121.0 (per the provided vendor advisory). For affected deployments, upgrading to 1.121.0 is the primary mitigation.

EPSS is predicted and rising per the findings; public EPSS values should not be used as a decision substitute for patching when an unauthenticated file read is possible.