n8n Shipped Eight Security Fixes in One Bulletin. Self-Hosters, This Is Your Weekend Homework.

Wednesday, October 14 was a busy day for anyone who runs their own automation stack. n8n published a security bulletin covering eight vulnerabilities, five of them classified as High severity, with fixes across every active release line. The same day, Censys released its 2026 State of the Internet report naming n8n the most exposed AI-adjacent product on the public internet. Exposure plus fresh flaws is the combination that turns a quiet Tuesday into an incident report, and this bulletin deserves your weekend.

This is not the first n8n security week of the month. Earlier in October, two CVEs landed in a single day: an expression sandbox escape (CVE-2026-86076) and an argument injection flaw (CVE-2026-44790, CVSS 9.4). The new bulletin is a separate batch, and the pattern matters. n8n's disclosure cadence is accelerating, which is good for transparency, but it means self-hosted instances fall behind fast if patching is a quarterly chore.

What the bulletin actually fixes

The eight advisories cluster around a theme: n8n is a workflow engine, so its attack surface is everywhere a workflow touches data. The five High-severity items are the ones to read first.

First, a stored XSS (CVSS 8.4): malicious HTML returned through webhook responses could execute JavaScript inside another user's authenticated session. In a shared n8n instance, your browser is the target, and an attacker only needs you to click through to an execution view. Second, cross-project data access (CVSS 7.2): a specially crafted workflow ID could let a restricted user read or modify Data Tables belonging to a different project. For teams using n8n's project isolation to separate client work, this one breaks the wall.

Third, a prototype pollution flaw in workflow history could cause denial of service. Fourth, a file operation denial of service: crafted glob patterns in the Read/Write Files node could block the application's event loop, hanging the instance. Neither is a breach by itself, but a hung or crashing automation server at 3 a.m. is exactly how on-call weekends begin. Fifth, credential exposure: certain node execution errors could reveal sensitive credential data to users with access to execution logs. Since n8n credentials routinely include Gmail tokens, Stripe keys, and database passwords, anything that leaks them into logs is a quiet catastrophe.

Which versions are patched

n8n released fixes across all active branches, so there is no excuse about waiting for your line to catch up:

On the 1.x line, update to 1.123.85 or newer. On 2.x stable, update to 2.43.5 or newer. On 2.x beta, update to 2.44.1 or newer. n8n Cloud instances were patched automatically, which is the entire point of paying for the managed tier. Self-hosted Docker users need to pull the updated container image and recreate the container while preserving persistent data. The reporting at bulletin date listed no confirmed active exploitation, which is reassuring right up until it stops being true.

The stored XSS and cross-project data access issues are the priority pair. Both require multi-user environments to be exploitable, which sounds like a limiting condition until you count how many self-hosted n8n instances actually serve a team, a family, or a client. If your instance touches credentials, API keys, or shared data, and other humans can create or edit workflows, treat this as urgent rather than routine.

For a workflow engine that holds your Gmail token, your Stripe key, and your database password, an unpatched server on the public internet is the worst kind of server.

Why this lands harder than a normal patch week

The Censys report that dropped the same day gives the bulletin its sting. Internet-facing AI infrastructure grew 63 percent in nine months, and Censys counted nearly 114,000 exposed n8n hosts, the most of any product it tracked. Axios, which reviewed the Censys data ahead of publication, reported that roughly 77,000 of those deployments were running versions affected by at least one recently disclosed critical vulnerability. We covered that exposure picture in detail when the report landed (114,000 exposed n8n instances and your hardening checklist), and the numbers have not gotten better since.

The calculus is simple. An unauthenticated vulnerability is worthless to an attacker who cannot reach your server, and devastating to one who can. Every self-hosted n8n with a public URL and an old version is a pre-authenticated target waiting for someone to connect the dots. Patching and reachability are two halves of the same fix: do them in that order and you are fine, do only one and you are exposed in a different way.

The weekend patch plan

If you self-host n8n, here is the order of operations, no drama required. First, back up before you touch anything. n8n's data lives in its SQLite file or Postgres database plus the N8N_ENCRYPTION_KEY. Back up both, because a failed upgrade without the encryption key means locked credentials and a very bad evening. Second, pull the fixed image and recreate the container, keeping your data volume intact. Check the version on first boot: the editor footer and the admin API both report it.

Third, check exposure while you are in there. From a network you do not control, a mobile hotspot works, try loading your n8n base URL and any known webhook endpoints. If you get a login form instead of a block page, you are reachable. The standard fix is a network boundary: restrict inbound traffic to a VPN or allow-listed IP ranges, and require authentication in front of every endpoint, the UI, the API, and the webhooks. Public test webhooks are the classic hole.

Fourth, review the logs and rotate secrets. Look for newly created users, newly added credentials, disabled MFA, and unusual spikes in workflow runs. If you have any reason to suspect the instance was reachable while vulnerable, rotate API keys, OAuth tokens, and database passwords, then invalidate active sessions. Fifth, minimize the blast radius: remove unused credentials, disable high-risk nodes you do not need, and make sure admin access uses strong multi-factor authentication. The credential-exposure fix in this bulletin is a reminder that execution logs are sensitive data now.

What comes next

n8n's security tempo is the real story here. October has already seen two CVEs on October 5, this eight-advisory bulletin on October 14, and a steady drumbeat through the year. For the project, faster disclosure is healthy. For self-hosters, it reframes maintenance: same-week patching for security releases is the goal, and a quarterly calendar reminder is the floor. If your n8n update process still involves a nervous evening of reading changelogs, this weekend is a good time to script it, pin your versions, and set up an external probe that alerts you if your n8n URL ever answers the public internet with a login form. The fastest win in all of self-hosting is being boring to the internet, and the second fastest is patching before someone notices you were interesting.