Act nowDisclosed

Advisory · CVE-2026-54309

n8n's browser bridge takes orders from strangers

When @n8n/mcp-browser runs in HTTP transport mode, its MCP endpoint accepts session and tool requests with no authentication, exposing browser control to any network client.

Advisory published June 23, 2026Independent summary
Vendor
n8n
Product
n8n
Identifier / CWE
CVE-2026-54309
CWE-306
Action timing
Immediate
ELI5

Explain it like I’m five

Your browser's remote control was left on the coffee table with no lock on it. Anyone on the network, or any website you happen to visit, can pick it up and drive your real browser, reading its cookies and saved logins.

SIMPLIFIED_ATTACK_PATH04 STEPS
  1. 01HTTP transport enabled

    The operator runs @n8n/mcp-browser with --transport http instead of the default stdio transport.

  2. 02Stranger opens a session

    Any network-reachable client, or any website the user visits, initializes an MCP session with no authentication.

  3. 03Browser tools invoked

    The caller invokes browser-control tools: navigation, JavaScript evaluation, cookie and storage access.

  4. 04Real profile exposed

    Where the n8n AI Browser Bridge extension is installed with an active connection, the attacker's commands run against the user's real browser profile.

What happened

n8n’s security advisory GHSA-qrx8-25qr-5r7v describes a missing-authentication flaw (CWE-306) in @n8n/mcp-browser. When run in HTTP transport mode, the MCP endpoint accepts session initialization and tool invocation requests without any authentication. Any network-reachable client, or any website visited by the user, can establish an MCP session and invoke browser-control tools. Where the n8n AI Browser Bridge extension is installed and a browser connection is active, an unauthenticated caller gains navigation, JavaScript evaluation, and cookie and storage access against the user’s real browser profile. Only instances running @n8n/mcp-browser with –transport http are affected; the default stdio transport is not. The issue is fixed in n8n 2.25.7 and 2.26.2. There is no confirmed public exploitation at the time of writing.

What to do

  1. Upgrade to n8n 2.25.7 or 2.26.2 or later.
  2. If you cannot upgrade immediately, stop running @n8n/mcp-browser with the HTTP transport and use the default stdio transport instead.
  3. If HTTP transport is required, restrict network access to the listening port to trusted clients only with host-based firewall rules.
  4. Treat browser profiles on affected hosts as exposed: rotate session cookies and credentials used in that browser, and review for unexpected navigation or script execution.

Management note

This is an MCP-shaped trust failure: a protocol meant for local agent-to-tool chatter was given a network listener with no authentication, and it landed with access to a real human browser. The blast radius is sessions and cookies, which are often the keys to everything else. If your automation stack runs n8n, check how the MCP components are exposed before assuming the automation network is a safe neighborhood.