The first thing I noticed was the login attempt timestamp. I was reviewing execution logs on a client’s self-hosted n8n instance, a t3.medium on EC2 running behind an Nginx reverse proxy, and in the same session I had the auth logs open in another tab. Eleven failed login attempts between 3:14am and 3:17am, all from the same IP block, all targeting the n8n UI path. Not the API. The UI. Whoever was probing the instance knew exactly what they were looking for, including the default port and the specific login endpoint. This was not a generic web scanner. This was something that knew n8n was there.
That was eight months before the Cisco Talos report surfaced. When I read it, I was not surprised. I was annoyed at myself for not writing about this earlier.
The Talos findings document threat actors actively targeting exposed n8n instances as initial access vectors, using them to execute code, exfiltrate credentials stored in the n8n credential manager, and in some cases pivot to internal services that the n8n instance had legitimate access to. If you have been self-hosting n8n for any length of time and you have built production workflows, you already understand why this is a serious problem. The n8n credential manager is where you store everything: API keys, OAuth tokens, database connection strings, service account credentials. A compromised n8n instance is not just a compromised automation tool. It is a compromised keyring for every service that automation has ever touched.
Here is the part the Cisco report documents but does not fully contextualise for people who actually build on n8n. The default self-hosted setup, the one in the official getting started documentation, the one most people follow the first time, does not enforce authentication in a way that survives real exposure. The documentation walks you through setting N8N_BASIC_AUTH_ACTIVE to true and choosing a username and password, and if you follow those steps you feel like you have secured the instance. What the documentation does not tell you, not in that section, not adjacent to it, is that basic auth over HTTP is not meaningful security, and that if your reverse proxy is not correctly enforcing HTTPS before the auth challenge, your credentials are travelling in a form that anyone on the network path can read. I found this out not from the docs but from a security-focused post in the community forum that I almost did not find because it was not linked from anything official.
The Code node is the other exposure surface that does not get discussed enough. One of the things that makes n8n genuinely more capable than Zapier or Make for complex workflows is that the Code node lets you run arbitrary JavaScript inside the workflow execution environment. That is also, from an attacker’s perspective, the most interesting feature in the product. If someone can get a malicious workflow onto your instance, through a compromised account, a shared workflow template with embedded logic, or direct API access to the workflow creation endpoint, they can execute code inside your infrastructure with whatever permissions the n8n process is running under. On a badly configured EC2 instance where the Docker container is running as root and the instance has an overpermissioned IAM role attached, that is a meaningful level of access.
I am not describing a theoretical attack surface. The Talos report describes observed exploitation. This is already happening.
The thing that makes me genuinely frustrated about where the conversation has landed in the n8n community is the number of responses to this report that defaulted to just do not expose it to the internet as if that is a complete answer. For a solo developer running personal automations on a private network, it might be. For anyone running client-facing workflows, webhook-triggered automations that by definition need to be reachable from external services, or multi-user instances where team members need access from different locations, do not expose it is not advice. It is an abdication.
The actual answer involves several things that the documentation should be more direct about. Network-level controls that restrict access to the n8n UI to specific IP ranges while keeping webhook endpoints public-facing. Environment variable configuration that disables the built-in credential UI when you are running in environments where credentials should be injected from a secrets manager instead. Regular audit of which workflows have active webhooks and what those webhooks accept. IAM roles for the EC2 instance scoped to exactly what n8n needs and nothing beyond that. None of this is exotic. All of it takes time that most people setting up n8n for the first time do not know they need to spend.
The n8n team has made a tool that is genuinely powerful and genuinely useful and I build on it daily. But the security documentation has not kept pace with the deployment reality, and the community culture around self-hosting has historically optimised for getting things working rather than getting things working safely. The Cisco Talos report is the point at which that culture needs to update.
An exposed n8n instance with stored credentials is not an automation tool someone can abuse. It is an unlocked door into every service you have ever connected to it.
Olaitan Oladipo holds a BSc in Sociology from Olabisi Onabanjo University. He is a self-taught automation builder who has spent years inside n8n doing the work that most tutorials skip: debugging OAuth errors at 2am, migrating client automations from Make.com mid-project, fighting reverse proxy misconfigurations on AWS EC2, and figuring out through trial and error what actually holds up in production versus what only looks clean in a demo.
He is not a developer by training and not a SaaS founder. He is the person in the Discord server who actually answers the question instead of linking to the docs.
His writing on n8n Automation Tutorial covers self-hosting, AI agent workflows, tool comparisons, and the security vulnerabilities the automation industry would rather not discuss. He has built AI-assisted invoice approval flows using OpenAI function calling, connected Claude via HTTP Request nodes, and holds considered opinions about Zapier, Make.com, LangChain, and CrewAI that their marketing teams would not appreciate.
He writes for people who are technical enough to follow a tutorial but experienced enough to want the honest version.
