TL;DR
Censys found 113,926 n8n servers reachable from the public internet. That doesn’t mean all of them were hacked or even vulnerable.
The real concern is what an automation server can access: email, customer records, databases and other systems connected through stored credentials.
I’d want every exposed automation service to have a named business owner, a reason to be public and evidence that its software and connected accounts have been checked.
Censys found 113,926 n8n servers exposed to the public internet. That’s a lot of automation sitting where anyone on the internet can find the service.
Before that number becomes a headline about another security disaster, there’s an important distinction. A server being reachable doesn’t mean somebody broke into it. Some workflows need public webhooks or forms to do their job. Others may be exposed without anyone realizing it.
I’m more interested in a question executives should be able to answer without calling six different teams: Which of those systems belong to us, and who is responsible for them?
n8n is a workflow automation tool. It can connect AI models to other applications, but workflows don’t have to use AI. A workflow might receive a form, update a customer record, create a ticket or send a message. Those steps often require credentials for the connected services.
So if someone compromises a badly configured automation server, the damage may not stop at the server. It depends on what accounts the workflows can access and what those accounts are allowed to do.
That’s a different conversation from asking whether your employees are using AI.
What the research actually says
On October 14, Censys published findings from its 2026 State of the Internet Report. Its measurements showed that the number of internet-facing hosts exposing AI-related tools grew more than 63% between October 2025 and July 2026.
The most widely exposed product in that group was n8n, with 113,926 hosts.
Of the n8n hosts whose software versions Censys could identify, 76% reported a version in the affected range of at least one recent critical vulnerability.
Read that carefully. The 76% doesn’t cover every n8n host. It covers the subset that reported a readable version number. And a version being in an affected range doesn’t tell us whether every condition for exploiting a particular bug is present.
These are worldwide measurements of internet-facing hosts, not counts of distinct companies or confirmed breaches.
That gives security teams a place to start: find their own exposed services, then check whether those deployments meet the conditions for a known vulnerability.
One workflow can reach a surprising amount of the business
Consider a hypothetical workflow built by a support team. A customer submits a request. The workflow reads the form, looks up the customer in a database, opens a support ticket and sends an update to a chat channel.
Perfectly reasonable automation.
To do that work, the server needs a way to authenticate to those systems. Maybe the customer database connection can only read a few fields. Maybe the support account can create tickets but can’t delete them. Or maybe somebody used a broad administrator credential because it was faster to get the workflow running.
Those are very different risks, even if the workflow looks identical to the employee using it.
If the server is compromised, what could someone do using the connections it already has? Read customer records? Change tickets? Send messages that appear to come from the company? Reach files or internal services?
Leadership needs to know the answers for its own deployment.
In Your AI Agent Can Commit the Company, I wrote about the business limits that have to exist before an agent is allowed to take action. This is the infrastructure side of that problem. Someone has to know what the server can reach before they can claim those limits are enforced.
A version number is only the beginning
In a January 8, 2026 security advisory, n8n described a file-access vulnerability affecting self-hosted versions 1.65 through 1.120.4. An unauthenticated person could read files from the host if it ran an active, publicly accessible workflow with a Form Submission trigger and a Form Ending node configured to return a binary file. The vendor said the issue was fixed in version 1.121.0, released November 18, 2025.
The advisory is an example of why configuration matters. Censys’s public summary doesn’t identify which vulnerabilities account for its 76%.
So a review can’t stop at finding an old version and declaring a breach. Check the exact configuration, the vendor’s advice, whether the update is installed and whether any sensitive data could have been exposed.
The same vendor provides a built-in security audit that can flag things such as unprotected webhooks, outdated versions, risky nodes and unused credentials. That’s helpful, but you still need to check how the service is exposed from outside and what its connected accounts can do.
And while n8n is the clearest example in this research, the ownership question applies to other automation tools too. Some run in your cloud account, some are managed by a vendor and some were built by one person to solve a problem everyone else was too busy to address.
What I’d ask before calling this handled
I wouldn’t ask the board to memorize n8n version numbers. However, I would expect the security and business owners to be able to show a few things.
First, find the services from the outside. Use an approved external exposure assessment, then compare what it finds against your cloud inventory, vendor list and known automations. If you only look at systems IT says it owns, you may miss the one someone stood up outside the normal process. Confirm ownership before touching or testing anything that’s not yours.
Next, name the business owner and the people responsible for running the service. The business owner should be able to explain why it’s needed and what it’s allowed to access. Name who handles patching and expired credentials, who responds to an incident and who takes over if the person who built it leaves.
Then, explain why it has to be reachable. Some workflows legitimately accept public requests. That doesn’t mean the editor, administration screens and other functions should automatically be accessible to everyone. Check which parts require public access and which can be restricted.
Finally, inspect what it can reach and verify the fix. Inventory the credentials and the permissions behind them. Remove access the workflow doesn’t need. Review the vendor’s security advisories, upgrade or apply the supported mitigation, then check again from outside. If there’s reason to suspect a compromise, investigate it before assuming a patch by itself closes the incident.
The part the inventory doesn’t tell you
I wrote about supplier visibility in You Can’t Patch a Supply Chain You Can’t Inventory. You need to know what’s installed before you can deal with it.
Here, there’s another question after you find the system: what authority did you give it?
Two automation servers can look equally exposed from the internet. One has limited credentials and accepts only a specific public request. The other can read a customer database and change records across several business applications.
I wouldn’t treat those as the same risk, and I wouldn’t be satisfied with a report that simply counts both as exposed.
Censys has given us a reason to look. The job for leadership is to find out what’s actually running, who owns it and how much access sits behind it.
If I were reviewing the results with a CISO, that’s the information I’d want on the first page. Not a green box that says the AI tools are approved.
The inventory question I'd add is whether the same credential shows up on more than one server: teams reuse one broad admin key across three or four automations because it worked the first time, so scoping access per workflow still leaves one leaked key with the run of every system it touches. Checking for credential reuse across the estate is the difference between an inventory and a blast-radius map.