The GitHub notification came in at 6:47am on a Tuesday and I almost dismissed it the way I dismiss most dependency update alerts, which is to say immediately and without reading. I had three client workflows running on a self-hosted n8n instance that I had set up seven months earlier on an EC2 t3.medium, Docker Compose, Nginx reverse proxy, the usual stack. The instance was behind a security group that I had configured carefully, or so I believed. The notification was a CVE advisory. Six of them, actually, published in a batch across a single January week, and when I read the first one properly I went and made a second coffee before I continued, because the kind of attention the rest of them required was not the kind I had available at 6:47am on a Tuesday without caffeine.
Six vulnerabilities. One month. And the honest thing to say about that is that n8n is not uniquely bad at security, it is uniquely exposed to a particular category of risk that comes with what it does, which is sit on your infrastructure, hold your credentials, have network access to your internal systems, and execute arbitrary code on a schedule. That combination means that when something goes wrong at the security layer, it does not go wrong in a small way.
The vulnerabilities that January covered a range that should have made anyone running a public-facing n8n instance uncomfortable. There was a server-side request forgery issue in the HTTP Request node, which is the node I use in roughly sixty percent of my workflows. The way SSRF works in this context is that a malicious workflow, or a malicious actor who has found a way to inject workflow configuration, can use the HTTP Request node to make requests to internal network resources that the n8n instance can reach but the outside world should not be able to. If your n8n instance is on the same VPC as your database, your internal APIs, your secrets manager, that is not a theoretical problem. That is a live attack surface.
There was also a credential exposure issue related to how n8n handles certain workflow exports, which I will not describe in precise technical detail here for reasons that should be obvious, but which meant that under specific conditions credentials stored in n8n could be included in exported workflow JSON in a way that was not visible in the UI. I checked every workflow export I had sent to clients in the previous three months after reading that one. Turned out I was clean, but the twenty minutes I spent checking was not a pleasant twenty minutes.
The documentation around the patches was where I started to feel the specific frustration that comes with open source security disclosures. The CVE notices were published. The patches were in the release notes. What was not in the release notes, or in any communication I received, was a clear statement of whether the vulnerability was being actively exploited in the wild, what the actual attack conditions were, and whether a self-hosted instance with my specific configuration profile, non-public IP, no anonymous workflow execution enabled, was actually at risk or theoretically at risk. That distinction matters enormously when you are deciding how fast to push an update to a production instance that has running workflows attached to it. Pushing an n8n update is not a one-click operation when you are on Docker Compose. You pull the new image, you check the breaking changes list, you test the workflows that are most likely to be affected, and you do this carefully because I have had a major version update break a Code node’s access to certain built-in modules and not find out until a production workflow failed silently at 3am.
I updated within forty-eight hours. The update itself was fine. But the window between reading the advisory and completing the update was two days during which I genuinely did not know how exposed I was, and the official channels gave me no useful help in answering that question.
Here is the part that applies to everyone who has followed a tutorial to get n8n running and considers themselves done. The default n8n Docker Compose setup, the one in the official docs and the one that roughly eighty percent of self-hosting tutorials reproduce, does not enable any of the security hardening options that n8n exposes. No IP allowlisting on the webhook endpoint. No restriction on which workflow nodes are available. No audit logging. These are all configurable. They are not configured by default. The documentation presents them as optional enhancements rather than baseline requirements for a production instance, which is a framing choice that I think reflects the priorities of a developer tool trying to minimise setup friction rather than the priorities of someone running live client workflows on the same machine.
LangChain, for what it is worth, has a worse record here than n8n does. The agent execution model that LangChain popularised involves giving a language model access to tools that can take real-world actions, and the security model around prompt injection in that context is still essentially unsolved. I have seen production LangChain deployments where the security consideration was not thought about at all, because the demos do not make you think about it. At least n8n publishes CVEs.
Self-hosting n8n is the right call for most serious use cases. But self-hosting means you own the security, and owning the security means reading the advisories, enabling the hardening options, and not treating a tutorial-level setup as a production-ready deployment just because it runs.
The six vulnerabilities in January were patchable. The assumption that someone else is watching your instance is not.
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.
