n8n Security: CVE-2025-68613 and Keeping the Editor Private

n8n security comes down to two habits: run a patched release, and keep the editor and its REST API off the public internet. Most self-hosted n8n instances are public for one reason, which is that Webhook nodes need a URL the outside world can call. You can serve that URL without exposing the editor by receiving webhooks through an outbound relay, so the login page and workflow editor are not reachable from the internet.

This post covers the n8n vulnerability record that matters (centered on CVE-2025-68613), what each flaw needs from an attacker, and how to set up n8n so only webhook deliveries arrive.

The n8n vulnerabilities worth knowing

Three n8n advisories explain most of the current n8n security discussion. The first is in our Threat Watch feed, which records verified facts; the other two we checked directly against n8n's own GitHub advisories.

Details worth keeping straight:

• CVE-2025-68613 affects builds from 0.211.0 up to the fixed releases. Per the vendor advisory, the workarounds (restrict who can edit workflows, harden the host) only reduce risk; upgrading to 1.122.0 or later is the fix. CISA published no victim or method details.
• CVE-2026-25049 is described by n8n as additional exploits in expression evaluation, found after CVE-2025-68613. Stopping at 1.122.0 is therefore not enough; move to a current release.
• CVE-2026-21858 affects versions from 1.65.0 before 1.121.0. n8n says there is no official workaround, and suggests restricting or disabling publicly accessible webhook and form endpoints until you upgrade. We did not find a Threat Watch record for it, so the link above goes to the vendor advisory.

One more n8n item is unrelated to self-hosting: in October 2026 the hosted creators portal served templates still in review without a login. A workflow template can embed API keys and webhook URLs, so if you submitted templates, rotate anything they contained.

Why exposure is the real risk multiplier

Two of the three flaws above need a valid account. That sounds reassuring until you look at what an exposed instance offers an attacker: a login page on the internet, reachable by every scanner, with a credential store behind it. Account takeover, a leaked password, a low-privilege user added for one project, or a phished editor all become a path to the host once an unpatched expression bug exists.

If the editor is only reachable from a private network or VPN, the same bug still exists, but the attacker must first get onto that network. Reducing who can even attempt a login is the cheapest layer of defense you have, and it does not depend on you winning every patch race.

Exactly what to expose, and what not to

n8n serves several things from one process. By default, per the n8n endpoint variables:

The Webhook node documentation confirms the two URL types: a test URL, registered when you select Listen for Test Event, and a production URL, registered when the workflow is published. Production calls look like https://<your-n8n-url>/webhook/my-path.

A conventional setup publishes the whole origin through a reverse proxy, then sets the public base URL so n8n shows the right webhook addresses. The reverse proxy guide says to set N8N_WEBHOOK_URL (it replaces the older WEBHOOK_URL, which the docs describe as deprecated) and N8N_PROXY_HOPS=1. That is correct for a proxied instance, but note what it implies: the editor and /rest/ are now on the internet too, unless you filter paths yourself.

Receive n8n webhooks without exposing the editor

Webhook Relay gives senders a stable public URL and delivers each request to n8n over a connection that n8n opens outward. Pick one of two paths.

Option A: the Webhook Relay Trigger node (no inbound listener)

This is the primary path, documented in the n8n Webhook Trigger tutorial. The node opens an outbound WebSocket, so nothing in n8n has to be reachable from outside.

1. In n8n, go to Settings > Community Nodes > Install and enter n8n-nodes-webhookrelay (npm package).
2. Create an API key at my.webhookrelay.com/tokens and paste it into a Webhook Relay API credential.
3. Add the trigger, give it a Bucket name such as n8n, and optionally set Endpoint Authentication (Basic or token) and the Response returned to the sender.
4. Copy the Public URL (https://<id>.hooks.webhookrelay.com) into the provider's webhook settings.
5. Activate the workflow. Test this trigger captures a single event; activating receives events continuously.

Because this node does not use n8n's own /webhook/ listener, you can bind n8n to a private address or put the editor behind a VPN or SSO without losing webhook delivery.

Option B: the relay agent forwarding to n8n's own webhook path

If you prefer n8n's built-in Webhook node, run the relay agent next to n8n and forward to the production path on a private address. The commands come from the localhost forwarding guide:

relay login -k YOUR_TOKEN_KEY -s YOUR_TOKEN_SECRET
relay forward --bucket n8n http://localhost:5678/webhook/my-path

Lock the destination path. By default an output appends any extra path the sender adds to the input URL (a POST to <input URL>/anything goes to <destination>/anything). Outputs created in the dashboard have Destination URL path locked switched on; outputs created with the CLI or API do not, so open the output and turn it on (API/MCP field lock_path: true). With the path locked, every delivery goes to exactly the destination URL and nothing else on n8n is reachable through the relay.

The command prints a permanent public input URL, which you give to the sender. Port 5678 is n8n's internal port per the n8n docs; adjust it if you changed it. While you build the workflow, a second bucket can point at the /webhook-test/ path the same way. For a server, the agent also runs as the webhookrelay/webhookrelayd Docker image (see Docker installation); use host networking when the destination is the Docker host's localhost.

With either option, close the inbound firewall rule and the proxy route to n8n. The relay's public URL is the only thing the internet sees.

Hardening that still matters

• Patch. The relay does not fix CVE-2025-68613 or its follow-ups. Run a current release, not just 1.122.0.
• Restrict workflow editors. Both expression bugs need permission to create or modify workflows, and n8n's workaround is to limit that to fully trusted users.
• Authenticate the sender. Set endpoint authentication on the trigger, or verify the provider's HMAC signature with a Webhook Relay function. See also how to verify a webhook signature and webhook security best practices.
• Filter before delivery. Drop events you never act on with filtering rules or a function so n8n workflows see less untrusted input.
• Run n8n with least privilege. Restricted OS privileges and limited outbound network access reduce what a code-execution bug can reach, as the vendor advises.
• Rotate stored credentials if the instance was internet-reachable while unpatched.

The same pattern applies to other self-hosted tools; see securing Jenkins and receiving webhooks in CI/CD.

Honest limits

A relay narrows what is reachable. It does not make every n8n flaw irrelevant.

• The webhook path can itself be vulnerable. CVE-2026-21858 involves form-based workflows and publicly accessible webhook and form endpoints. If your sender can reach a vulnerable workflow through the relay (Option B), a crafted request is still delivered. Verify the provider's signature at the relay with an HMAC function so unsigned requests are rejected with a 401 before they reach n8n, forward only the specific paths you need, and patch.
• Public forms are n8n's own surface. If you need n8n-hosted public form pages, the relay does not replace that listener. Treat those as exposed and keep them patched.
• Users who need the editor from outside need a VPN, SSO-aware proxy or similar. The relay solves webhook delivery, not human access.
• Authenticated attackers. Anyone with a legitimate account on an unpatched instance can still use CVE-2025-68613. The relay removes the public login prompt; it does not remove the bug.
• The relay is a new trust point. Keep verifying signatures at n8n or at the relay.

Next step

More self-hosted tools that are public only for webhooks

• Jenkins vulnerabilities exploited in the wild
• TeamCity CVE-2023-42793 and CVE-2024-27198
• Langflow vulnerabilities, from CVE-2025-3248 on
• Kestra security and CVE-2026-49869

If your n8n is public today only so Webhook nodes can receive events, that is the first thing to change. Create a free Webhook Relay account, follow the n8n Webhook Trigger tutorial, then close the inbound route.