Ok I’ve just come across some pretty disturbing stuff today in the fundamental build of n8n.
I’m talking about the exposed and served directory /types/ under /home/node/.cache/n8n/public/types/.
Particularly the serving of nodes.json and credentials.json.
Now I know that these are just JSON descriptor files required for the frontend UI and aren’t housing any node configuration or credential data, but it’s a potentially huge issue and I’m surprised that it’s designed like this at all.
Because there’s a real potential DDoS bottleneck here with the serving of these two files.
Especially in regards to nodes.json.
nodes.json is an approx. 13.6MB JSON file that describes all available nodes for the frontend UI, and yes it’s just metadata for node rendering.
But here’s the problem: it’s served publicly.
I ran a quick test using this:
while true; do
curl -s https://<your-n8n-domain>/types/nodes.json > /dev/null
done
Within a couple of seconds, my n8n instance started choking, right up till it stopped responding entirely in the browser.
Now this is hosted on a beefy VPS box (4 GB / 2 Intel CPU) running n8n in an optimised docker container on DigitalOcean, and while the graphs spiked of course, n8n was down for the count.
CPU usage shot up, UI refused to render, and the whole instance was limping.
That was a single-threaded curl loop on a mid-tier connection, imagine a few distributed bots doing that all at the same time.
It’s a damn low-effort, high-impact DDoS vector
Blocking the /types/ directory with your reverse proxy sounds like a logical solution to limit exposure, but you can’t because the second you do n8n thinks there aren’t any nodes installed in your instance.
Honestly? This feels pretty dumb by design.
It also allows for a bad actor to probe the files and figure out which version of n8n the host is running, and whether it’s a viable candidate for other vectored attacks (login/DB/credential/brute) if there are known vulnerabilities.
I absolutely love n8n and honestly am a little shocked at this. And before anyone asks, I’m running 1.94.1
I’m not directly calling this a leaky security hole, but it’s definitely something that needs a massive rethink. Especially considering the number of n8n instances in the world right now.
If you’re self-hosting, do yourself a favour:
- Put n8n behind a proper reverse proxy (Caddy, Nginx, etc.)
- Add rate limiting or edge caching
Would love to hear if the n8n team has any plans to make this endpoint less of a liability.