Exposed n8n Instances: Why Workflow Automation Servers Are a Prime Target
Internet-facing n8n servers hold the keys to your connected apps and AI agents. Learn how to find exposed instances, why CVE-2026-21858 mattered, and how to lock n8n down.
What is n8n and why does it matter?
n8n is a popular workflow automation platform. Teams use it to connect applications, move data between systems and, increasingly, to wire AI models and agents into business processes. It is often self-hosted, frequently by a single engineer, and often reachable from the internet so that webhooks and forms can work.
That combination makes it a high-value target. An n8n server typically stores credentials and API tokens for every system it talks to: email, CRM, cloud storage, databases, chat tools and AI providers. Whoever controls the server can usually use all of those connections.
How big is the exposure?
In October 2026, Censys reported nearly 114,000 internet-facing n8n deployments, the most widely exposed AI-related product in its dataset. Roughly 77,000 of them were running versions affected by at least one recently disclosed critical vulnerability (Axios, 13 October 2026).
Two caveats matter. Being exposed and running an affected version does not prove an instance can be exploited, and the data does not show how many were actually compromised. Still, it shows how many organisations are one unpatched component away from a serious problem.
Case study: CVE-2026-21858 ("Ni8mare")
In January 2026, a critical vulnerability was disclosed in n8n and rated CVSS 10. Key facts:
- No authentication required. A remote attacker could exploit it against a vulnerable workflow without credentials.
- Where it lived. The flaw was in webhook and file-handling logic, specifically form-based workflows. Changing the content type of a request made n8n use the wrong parser, which allowed an attacker to read arbitrary local files.
- Why it was serious. Researchers showed that reading n8n's configuration and database files gave them what they needed to forge an administrator session and then create a workflow that runs commands on the host.
- Fix. n8n 1.121.0 (released in November 2025) contains the fix. Instances running older versions should be upgraded.
- Reported by Dor Attias of Cyera Research Labs. See the SecurityWeek coverage and the Censys advisory for details.
The lesson is broader than one CVE. Any service that accepts input from the internet, stores powerful credentials and is run by a small team deserves the same discipline as your primary web application.
How to check whether your n8n is exposed
- Find every instance. Search your cloud accounts, container hosts and DNS records for n8n. By default it listens on port 5678, but it is usually placed behind a reverse proxy on 443 under a name like
automation.orn8n.. - Test from outside your network. From a machine that is not on your VPN, request the login page and your webhook paths. If you can reach the editor UI, anyone can.
# From an external host
curl -sI https://automation.yourcompany.com/healthz
curl -sI https://automation.yourcompany.com/signin
- Check the version. Look at the image tag or package version. Anything older than the latest release deserves an immediate update, and anything older than 1.121.0 is affected by CVE-2026-21858.
How to lock n8n down
- Upgrade first. Move to a current release and subscribe to n8n's security advisories.
- Do not expose the editor. Put the UI behind a VPN, an identity-aware proxy or an IP allowlist. Only the specific webhook and form paths that must be public should be reachable from the internet.
- Enforce strong authentication. Use SSO or strong passwords with MFA for every user, and remove unused accounts.
- Reduce what a compromise can do. Use scoped, least-privilege credentials for each integration. Consider disabling nodes that run shell commands (n8n supports excluding nodes through its configuration) if you do not need them.
- Protect the encryption key and database. Keep n8n's encryption key and database credentials out of images and repositories, and back them up securely.
- Rotate credentials after any suspected exposure. If an unpatched instance was reachable from the internet, treat every credential stored in it as potentially exposed and rotate it.
- Log and alert. Send access logs to your monitoring and alert on new workflows, new credentials and unusual executions.
How SurfaceScan helps
Most n8n exposure starts as an asset nobody tracked: a forgotten subdomain, an unexpected open port, or a host that was supposed to be internal. SurfaceScan continuously discovers your internet-facing hosts, subdomains and open ports, and flags changes when something new appears. An unexpected service on a new subdomain or non-standard port shows up as a change you can investigate before an attacker finds it. Review the related guides on open ports and what Shodan reveals to see how attackers find these systems.
Related articles
Exposed AI Agent Control Panels: Dashboards That Should Never Be Public
Admin panels for AI agents and LLM tools often connect to email, files and internal systems. Learn why exposed control panels are dangerous and how to secure them.
Exposed MCP Servers: When AI Tool Endpoints Are Open to the Internet
Model Context Protocol servers give AI agents access to databases, files and systems. Learn why internet-exposed MCP servers are risky and how to secure them.
Open Ports: Which Ones Are Dangerous and How to Close Them
Not all open ports are a problem, but some should never be exposed to the internet. Learn which ports are dangerous, why, and how to close them safely.