CVE-2026-21858 n8n: max severity RCE affects 100k servers

CVE-2026-21858 is a reported maximum severity vulnerability (CVSS range 9.x to 10.0, official score pending NVD confirmation) in n8n that allows an attacker to gain full control over the affected server. n8n is an open automation platform used by organisations to orchestrate integrations, AI agents, workflows across hundreds of enterprise services and internal databases. According to the researchers who reported the vulnerability, approximately 100,000 n8n servers are accessible globally, many without the hardening needed to resist a targeted attack. For organisations that have adopted n8n as their AI automation layer, this CVE represents the worst-case scenario: a single request can compromise the full host and, from there, the secrets of hundreds of connected integrations.

This Secra advisory summarises the technical nature of the flaw, affected products and versions, immediate mitigations, fit with NIS2 and DORA, and reflection on the emerging risk of AI automation platforms in production.

Key takeaways on CVE-2026-21858

• Critical vulnerability in n8n, AI automation and workflow orchestration platform.
• Reported maximum severity (CVSS range 9.x to 10.0, official score pending NVD): allows remote code execution (RCE) without authentication or with minimal authentication.
• Approximately 100,000 n8n servers accessible globally are in scope.
• Collateral impact: once the n8n server is compromised, the secrets of every connected integration (Slack, Google, AWS, databases) are exposed.
• Mitigation: update to the latest n8n version + isolate the n8n instance + rotate credentials if exposure is suspected.

What CVE-2026-21858 is

CVE-2026-21858 is a maximum severity vulnerability documented in n8n, an open-source and commercial automation platform used to connect APIs, run AI agents and orchestrate workflows across hundreds of SaaS services and internal tools. The vulnerability allows an attacker to execute arbitrary code on the server hosting n8n, with the service process privileges (typically a dedicated user but often with access to valuable credentials and internal network).

n8n has become especially popular in 2025 and 2026 as an orchestration layer for AI agents and workflows combining LLMs with legacy systems. That same popularity makes it a high-value target: a typical n8n server stores credentials for Slack, Google Workspace, AWS, GitHub, internal databases and, frequently, OpenAI or Anthropic API keys.

Why this matters specifically

Three combined reasons:

1. Concentration of secrets. An n8n server is, by design, a centralised store of credentials and tokens. Compromising it equals compromising all connected integrations.
2. Privileged network position. n8n is usually deployed in networks with access to internal systems to automate back-office tasks. It is a natural pivot toward sensitive infrastructure.
3. Deployments without hardening. Rapid n8n adoption by non-security-specialised teams generates many deployments without reinforced authentication, without proper TLS, exposed to the Internet by configuration error.

The approximately 100,000 n8n servers accessible globally represent a considerable attack surface. An automated scanning tool like Shodan can identify them in minutes.

Affected products and versions

The vulnerability affects n8n versions prior to the official patch published by the project team. Both the community (open-source) and cloud editions require verification:

• n8n self-hosted (community): affected versions per the official advisory. Verify exact version with n8n --version and consult release notes.
• n8n self-hosted (enterprise): same codebase, same affected versions. Consult the n8n team for specific confirmation.
• n8n cloud: the n8n team applies the patch centrally, but confirm the mitigation date in the customer panel.

For production environments it is critical to identify all n8n instances (including "shadow IT" instances that product teams may have deployed without coordinating with security).

Immediate mitigations

Action one: update to the latest version

Apply the update published by the n8n team. In Docker environments, this typically requires a pull of the new image and container restart. In orchestrated deployments (Kubernetes, Docker Swarm), follow the corresponding rolling update procedure.

Action two: isolate the instance

While completing the patch rollout:

• Restrict network access to n8n to corporate IPs or via VPN. Block access from the open Internet.
• Verify the n8n server is not accessible on default ports without protection
• Review firewall rules to limit outbound connections from the n8n server to strictly necessary destinations

Action three: rotate credentials if exposure is suspected

If the instance was exposed to the Internet before the patch, assume potential compromise:

• Rotate all credentials stored in n8n (Slack, Google, AWS, GitHub, OpenAI, Anthropic, databases)
• Audit connected integration logs for anomalous activity after n8n deployment
• Review existing workflows for unauthorised modifications

Action four: permanent post-patch hardening

• Enable authentication (basic auth, SSO, MFA) on the n8n interface
• Configure TLS with valid certificate for all connections
• Apply least privilege in workflows: each stored credential should have the minimum required scope
• Enable comprehensive logging and export to corporate SIEM

Action five: review AI workflows in production

For organisations using n8n to orchestrate AI agents and LLMs:

• Validate OpenAI, Anthropic or other LLM provider credentials have rate limits and restricted permissions
• Verify workflows invoking LLMs properly sanitise inputs (combined RCE + prompt injection risk)
• Review separation between sensitive data and prompts to public LLMs

Fit with NIS2, DORA and vulnerability management

This CVE exemplifies an emerging risk that NIS2 and DORA cover explicitly:

• NIS2 article 21.2(e): supply chain security. n8n is a vendor tool, its security affects the organisation.
• NIS2 article 21.2(j): policies and procedures to evaluate effectiveness of risk management measures.
• DORA article 28: ICT third-party risk management.
• ISO 27001:2022 control A.5.19: information security in supplier relationships.

An automation tool with access to corporate credentials that is not monitored or patched with discipline is a single point of massive failure. This CVE demonstrates it clearly.

The emerging risk of AI automation platforms

n8n is not the only case. Similar platforms (Make, Zapier, Apache Airflow, dagster, Prefect) and AI agent orchestrators (LangChain server, LlamaIndex servers, AutoGen) present analogous risk profiles: high credential concentration, privileged network position, rapid adoption without systematic security audit.

For 2027 we anticipate significant growth of CVEs in this category as adoption generalises and researchers focus there. Organisations deploying these tools must treat them as critical infrastructure from day one: hardening, monitoring, in-SLA patching and regular security audits.

Frequently asked questions

Is my n8n instance affected if it is not exposed to the Internet?

The risk is significantly reduced but not zero. An attacker with internal network access (compromised VPN, internal employee, supply chain) can exploit the vulnerability. Defence in depth remains necessary.

Can I temporarily disable n8n as mitigation?

Yes. If the update requires a formal change window, stopping the service during the interval prevents new exploitation. Re-enable only after patching.

How do I identify all n8n instances in my organisation?

Combination of formal server inventory, internal network scanning for the default port (5678 in many configurations), Docker repository search and queries to product/data teams to identify unofficial instances (shadow IT).

What about stored OpenAI or Anthropic credentials?

Assume compromise if the instance has been exposed. Rotate immediately. Audit recent usage looking for unauthorised calls, anomalous spending, suspicious prompts. Notify the LLM provider if applicable.

Does this affect workflows that move personal data?

Yes. If workflows process personal data under GDPR, an exploit that exfiltrates that data constitutes a notifiable breach. Document the corresponding risk evaluation.

Is n8n safe to use after this CVE?

Yes, once patched and with proper hardening. Like any software, n8n requires disciplined security maintenance. The vulnerability being reported and patched is a sign of a living ecosystem, not of an inherently insecure product.

Related resources

• What is a CVE: how CVE-2026-21858 gets referenced and prioritised.
• What is an exploit: max severity vulnerability vs available working exploit.
• What is prompt injection: combined risk in n8n workflows with LLMs.
• Cybersecurity audit business guide: include automation tools in scope.
• Secra security research and advisories.

n8n validation and audit with Secra

Secra runs an internal CVE research programme with advisories published on NVD and INCIBE-CERT (CVE-2025-40652 in CoverManager and CVE-2023-3512 in Setelsa ConacWin CB, among others). That discovery discipline applied to tools in your organisation is the difference between detecting exposure to CVE-2026-21858 before or after the incident.

We help organisations assess real exposure of their n8n instances and other AI automation platforms: inventory, hardening review, post-patch validation, retrospective threat hunting and, when applicable, DFIR intervention. For companies deploying AI agents in production we include specific LLM workflow audit (prompt injection, excessive agency, sensitive data exposure). Express audit of exposed n8n instances with first findings in under 5 days. Get in touch through contact.