Case study: an n8n webhook opened administrator accounts

Key facts

Context: what happened on this training platform?

A French online training platform (a very small business), open by invitation only, had an external audit in early 2026. The finding fits in one sentence: a plain n8n webhook, callable by anyone, let a visitor create accounts with the access level of their choice even though public sign-up was disabled.

The platform combined three common building blocks: a single-page web app, a Supabase backend (Postgres database, authentication, generated APIs) and an n8n server that automated admin tasks such as account creation. The team had disabled public sign-up, checked read access to the data and secured payments. On paper the platform was closed. In practice, a side door built for the administrator's convenience bypassed all of those protections.

This case study is anonymized. We do not name the client, its product or its hosting, and we publish nothing that would let anyone reproduce the attack.

Scope and authorization: under what conditions did the audit take place?

The audit was an authorized, paid, read-only engagement run from the outside, with the viewpoint of a visitor or attacker without an account. No account was created and no data was modified.

These are the rules we apply to this kind of engagement:

• Only publicly served resources were analyzed: pages, JavaScript files, API responses.
• The account-creation endpoint was not called. The proof of concept relied on reading the code sent to the browser.
• A single webhook received an empty request, to confirm that it answered without authentication. That action is recorded in the report.
• No personal data was downloaded or kept. Tests stop at confirming that data is readable.
• Temporary files were deleted at the end of the engagement.

This discipline matters as much as the finding. A report must prove the risk without carrying it out.

What we found: four findings, one of them critical

The critical finding is an account-creation webhook with no authentication at all, whose address was written in the site's code. Three medium-severity findings made it worse.

1. Critical: unauthenticated account creation. The admin interface sends the future user's details (address, name, password, access level) to an n8n webhook. No authentication header, no token. The webhook address sat in a JavaScript file that any visitor could download.
2. Medium: missing security rules for updates and deletions. At database level, row-level security (RLS) policies blocked inserts, but no policy covered updates or deletions.
3. Medium: three publicly callable n8n webhooks. All their addresses were present in the site's code. A test with an empty request confirmed that a workflow started without any check.
4. Medium: n8n server directly exposed to the internet. The server was up to date at the time of the audit, but an automation instance reachable from anywhere remains a permanent attack surface.

The first finding is the one that hurts. The other three explain why it became so serious.

The attack chain: how do you go from anonymous visitor to administrator?

The chain has three conceptual steps and, based on our analysis, takes under two minutes for a motivated attacker. We did not run it end to end, out of respect for the read-only rule, but each link was checked separately.

1. Discovery. The admin interface code, served publicly, contains the webhook address and the exact shape of the data it expects. Reading that code is enough.
2. Creation of a privileged account. The webhook accepts the request without checking who sent it. The attacker chooses the access level, including the highest one in the product. With public sign-up disabled, this webhook becomes the only way in, and it is wide open.
3. Privilege escalation. Once logged in, the user can change their own rights. The roles table had no UPDATE RLS policy: the database accepted the request without a security error. The account becomes an administrator, with access to profiles, coaching sessions, purchases and login logs.

None of these links is sophisticated. Their combination is what produces a complete takeover. Any team would reasonably have rated finding 2 as medium in isolation, which is exactly why an audit must chain findings instead of listing them.

What held up: which controls worked well?

Several protections were correctly in place, and the report says so, because an honest audit also describes what resists.

• Read access to data was locked down. The vast majority of tables returned an empty result to an anonymous visitor. The usual workarounds (GraphQL queries, joins through the API) got nowhere.
• Inserts were blocked on all tables.
• The payment provider's webhook verified the signature of incoming calls. That is the right model, and the contrast is striking: on the same n8n server, one webhook was protected and another was not.
• The n8n REST API was protected: every unauthenticated request was refused.
• Email sign-in links and password reset revealed nothing exploitable, and no payment secret appeared in the site's code.

These points show a team that cares. The flaw comes from a blind spot: internal automations were not treated as an attack surface.

Fixes: what do we recommend to a small business?

The fixes are cheap and take a few hours to a few days. We ranked them by urgency.

Immediate

• Authenticate every n8n webhook with a secret that only the application's server knows. n8n offers native authentication methods on the Webhook node.
• Add UPDATE and DELETE RLS policies on all tables, starting with the roles table.

This week

• Move admin operations server-side (a server function or Edge Function that verifies the administrator's identity) so the browser never calls the webhook directly.
• Remove webhook addresses and any secret from the code sent to the browser.
• Restrict network access to the n8n server (VPN, allowlist) so it is no longer publicly exposed.

This month

• Apply least privilege: a logged-in user must not be able to change their own role or rights.
• Review the RLS policies for authenticated accounts, not only for anonymous visitors.

What this changes for an AI agent: why this case study concerns us

An n8n workflow or webhook is exactly the kind of tool an AI agent calls. If access control is missing on that entry point, the same flaw becomes an action an agent can trigger, including under the influence of malicious text.

Here, a human read the code to find the webhook. Replace that human with an agent wired to its tools through function calling or an MCP server. The agent receives an email, a document or a web page containing hidden instructions (indirect prompt injection). Among its tools is "create a user", connected to an open webhook. No human validates the action, and no authentication separates the legitimate request from the injected one. This is the scenario OWASP calls excessive agency (LLM06 in the Top 10 for LLM Applications 2025).

Three lessons carry over directly:

• The security barrier must live outside the agent. Rules written in a prompt are soft. The decision to allow an action must live in the system that executes it, with authentication, a narrow scope and logging.
• Every tool of an agent is an attack surface. The MCP server, webhook or workflow must verify the caller and the right to act, just as a publicly exposed API would.
• Chains matter more than isolated findings. A permissive tool, an overly open database and an injected instruction are enough to produce an incident.

To go further, read our page on AI agent security, the one on MCP security and our approach to AI agent red teaming. The Agent Red Team Express offer applies this chain logic to your agent in five days.

Result: what did the client get?

The client received a full report, an executive summary with priorities for today, this week and this month, and the list of controls that worked. The critical findings were presented with their exploitation chain so that the fix targets the cause (missing access control) and the visible symptom (an exposed address).

The takeaway for any team automating with n8n, Make or Zapier: inventory every webhook, check who can call it, and treat automation as a public API. If an AI agent relies on those automations, this work becomes your agent's first line of defense.

Further reading

• Another case study: a Supabase paywall bypassed in two requests

What happened next: the re-test

We came back to this platform a few weeks later for a second authorized penetration test, from the same vantage point: an anonymous external attacker with no account, registration still disabled. The question was direct: does the fix for the critical flaw hold, and what was left open elsewhere?

What was fixed. Unauthenticated account creation, the entry point of the whole chain, is gone. The webhook addresses no longer appear in the JavaScript served to visitors, and account creation now goes through a server-side function that checks the caller's identity and role before acting. The missing row-level security policies for updates and deletions are in place too: an anonymous attempt to change or delete a row no longer affects anything. Reading training content, previously partly open, now returns empty results. The schema exposed by the API was largely hidden, with a remainder on the generic query side.

What remained. The re-test closed with zero critical findings, one high, eight medium and five low. The high finding fits in one sentence: the browser extension offered to the public embedded the addresses of three automation webhooks with no authentication. Anyone could use paid features for free, at the expense of the owner who pays the usage costs, and trigger sign-in emails. The fix had been applied to the website, but not to this second surface.

The medium findings are platform hygiene: insufficient throttling of login and verification attempts, paid content reachable through a public link, anonymous writes possible into an error log, a bypassable origin check on video delivery, missing security headers, and public client registration on the automation server. Nine further leads tied to business logic could not be confirmed without an account.

The lesson. Fixing a flaw closes one door. The re-test showed that the same design mistake, automations callable by anyone, persisted elsewhere in another form. The same reflex applies to AI agents: every tool, webhook and extension is an entry point that must be authenticated. We recommend a full inventory of entry points after any fix, followed by a new test. See also the Agent Red Team Express.

Other case studies

• Supabase paywall bypassed in two requests
• AI writing SaaS application
• Crypto-asset exchange platform
• Restaurant: back office opened by a forgotten file