I was in the middle of debugging a webhook timing issue on a client’s n8n instance when the message came through on Discord. Someone posted a link, no context, just the URL and a single line: “everyone running self-hosted needs to read this now.” I finished what I was doing, which took another twenty minutes because the issue turned out to be that the Respond to Webhook node was sitting after a Code node that was occasionally taking longer than the default timeout allowed, and then I clicked the link.
The CVE listing was real. A critical vulnerability in a widely deployed automation platform — not n8n specifically, but one of the integration middleware layers that sits underneath a significant portion of how these tools talk to external services — had been added to CISA’s Known Exploited Vulnerabilities catalogue. The kind of listing that means it is not theoretical. It means someone is actively using it.
I want to be clear about what that moment felt like, because I think the way the security community discusses these things often skips the part that is actually relevant to people running production automation infrastructure. It did not feel like a distant enterprise problem. It felt like a question about every credential I had stored, every webhook endpoint I had exposed, every HTTP Request node pointing at a client’s internal system with a Bearer token sitting in plaintext inside an n8n credential that was itself sitting inside a Docker volume on an EC2 instance with a security group I had configured eighteen months ago and not reviewed since.
That is the specific dread. Not the CVE number. The inventory.
The platform in question is not one I will name here because the details are still developing and I am not interested in piling onto a vendor who is presumably having the worst week of their engineering team’s life. What I will say is that the vulnerability class, an authentication bypass in the credential storage and API key handling layer, is exactly the kind of thing that self-hosted automation infrastructure is structurally exposed to in ways that cloud-hosted platforms are not, and also exactly the kind of thing that cloud-hosted platforms create different versions of that nobody talks about honestly.
Here is the part that the Zapier sales deck will never say out loud. When you run everything through a managed cloud platform, you are not solving the credential security problem. You are outsourcing it to a company whose security posture you cannot audit, whose breach notification timelines are governed by their legal team, and whose incident response you will read about in a TechCrunch article three weeks after it happened. I have watched clients treat Zapier as inherently more secure than self-hosted alternatives because it is managed, and that logic is doing work it cannot support. Managed means someone else is responsible. It does not mean the risk is gone. It means the risk is less visible to you.
Self-hosting n8n on EC2 with Docker Compose means the risk is entirely visible. Sometimes too visible. When I first set up the stack, I got the reverse proxy wrong, exposed the n8n port directly, had a brief period where the instance was accessible without authentication, and caught it because I happened to check the nginx logs while looking for something else. That was luck. Good documentation would have been better, and the n8n docs at the time were honest about what to configure but not direct enough about what happens if you do not configure it before the instance is publicly accessible. I added that to the list of things I tell people before they start the setup, not after.
The broader point is that the 80,000 companies running automation platforms, across n8n, Make, Zapier, Tray, and everything else sitting in that middleware layer, have a shared infrastructure problem that the industry has been comfortable not discussing because the tools are sold primarily on capability and ease, not on what your attack surface looks like when you have connected them to forty different services and handed out credentials to three different contractors over two years.
LangChain made this worse in a specific way. When AI-assisted workflow building became a thing people actually deployed, the number of HTTP Request nodes pointing at external LLM APIs multiplied quickly, and with them the number of API keys being stored in credential managers that had not been designed with the assumption that they would be holding keys to systems capable of generating and acting on arbitrary instructions. The demo of an AI agent that can read your email and take actions in your CRM is impressive. The security model underneath it is often an afterthought, and I say that as someone who built exactly that kind of flow for a client and spent less time on the credential isolation than I should have.
CrewAI is not production-ready for anything client-facing, and part of the reason is that the security and audit surface of multi-agent systems, where one agent’s output becomes another agent’s instruction, is not a problem anyone in that ecosystem has solved convincingly yet.
What the CISA listing should actually prompt is not panic about a specific CVE. It should prompt every person running automation infrastructure to open their credential list right now, count how many active tokens are in there, and ask honestly how many of them belong to services that would cause serious damage if those tokens were used by someone else.
Most people will find the number is higher than they expected, and the documentation for rotating those credentials will be harder to find than it should be.
That is the actual vulnerability. The CVE is just the reminder.
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.
