n8n fixes a batch of high-severity holes every fortnight, and nothing tells you

A release note that fixed nineteen things and said nothing

Here is the entire body of the n8n 2.37.7 release, published on 2 September 2026, with an auto-generated advertisement for an unrelated tool removed:

2.37.7 (2026-09-02)

That is not an excerpt. That is the whole release note — a heading, a version number and a date, about six hundred bytes of which are the advertisement.

That release closed five High-severity and fourteen Medium-severity security advisories, including two rated 8.7. Nothing in the note says so. Nothing in it says anything.

The sibling release on the older line, 1.123.76, does have exactly one line of changelog. It reads:

Bug Fixes

• core: Bump browserslist to 4.28.7 to clear CVE-2026-73088/73089

That release also fixed twelve n8n advisories. The one CVE number it names belongs to somebody else's package.

What was actually in the box

The 2 September batch was eighteen advisories, published between 12:33 and 12:56 UTC, with a nineteenth arriving the next morning. Five were rated High:

The unauthenticated one is the one to read twice. In n8n's own description:

The OAuth Dynamic Client Registration endpoints validated field sizes only for redirect_uris, leaving client_name and grant_types bounded by presence checks alone. An unauthenticated remote caller could submit arbitrarily large values in either field and have them persisted to the database. Repeated registration therefore grew persistent storage without limit and without any account on the instance.

• GHSA-hh89-3r9w-qj3j, n8n security advisory, 2 September 2026

"Without any account on the instance" is the phrase that decides whether this is your problem. It affects the 2.x line only, and the damage is availability rather than theft — the disk fills up and the instance stops. Everything else in that table needs a second human with editing rights, which for a one-person instance means the list of five collapses to a list of one.

The Git node one is worth a second look for a different reason. The regular expression that backtracks catastrophically was n8n's own shipped default for N8N_BLOCK_FILE_PATTERNS, not something an operator wrote. One workflow execution could freeze the instance for everyone, with, in the advisory's words, "no unusual configuration".

Every fourteen days, since June

One batch of nineteen would be an event. It is not an event.

(The nineteenth advisory of the September batch was published the following morning, which is why that row says eighteen.)

Every fourteen days since 10 June, with no exceptions and no gaps — a Wednesday each time. That is ninety-nine advisories in sixteen weeks, fifty of them High and three Critical, as the count stood on 8 September 2026, and if the fortnight has held, two more Wednesdays have come round since.

Two things follow from a rhythm that regular, and they point in opposite directions. The first is reassuring: somebody at n8n is running a serious, continuous security programme, and the fixes were on npm and Docker Hub before the advisories went up — releases at 07:37, 07:44 and 08:41 UTC, advisories from 12:33. Patch availability is not the problem here in any sense.

The second is the whole article. A fortnightly restock of high-severity holes is only useful to you if you find out it happened.

Nothing recent has a CVE

Across the hundred most recent advisories in the n8n repository, twenty-one carry a CVE identifier and seventy-nine do not — and every one of the twenty-one was published before the end of July. Nothing published since 5 August has one at all: not the seventeen from that batch, not the nine from 19 August, not the nineteen from 2 September.

This is not a bookkeeping detail. It decides which tools can see the problem. A scanner keyed on CVE identifiers finds nothing about anything n8n has shipped since July. Neither does a compliance process that tracks CVEs, or a hosting provider's vulnerability report on your container.

CVEs do arrive, downstream and weeks later — the records for several July advisories were updated with identifiers in August, and one from that period acquired the alias CVE-2026-77068 in a third-party database. Weeks later is doing a lot of work in that sentence when the cadence is fourteen days.

The second-order effect is worse, and it is measurable. On 8 September, the global GitHub Advisory Database — the one npm audit and Dependabot actually read — carried n8n advisories no newer than 22 July. Forty-five of the hundred repository advisories were missing from it, and those forty-five were exactly the August and September batches. The public OSV database was in the same state. Direct lookups for the 8.7 storage exhaustion advisory returned "Not Found" from both.

Five places you might expect to hear about it

Each of these was checked on 8 September 2026.

The release notes on GitHub. Empty, as above. Grepping the bodies of the forty most recent releases for the word "cookie" returns zero hits, which will matter in a moment.

The release notes in the documentation, and their RSS feed. The feed exists and answers. The page describes itself as "a running log of feature-level updates from each n8n release", and that adjective is load-bearing: its version headings run 2.38.1, 2.37, 2.36, 2.35.4, 2.35, 2.34 and so on. The security patch releases — 2.37.7, 1.123.76 — have no entry at all. Searching that page's source for "vulnerability", "advisory", "CVE" and "GHSA" returns zero hits each.

An RSS feed for the advisories themselves. GitHub does not serve one. The URL you would guess answers HTTP 406.

The in-app version notification. This one is the sharpest, and it gets its own section below.

Your email. Nothing documents a security mailing list for self-hosted users. I could not prove one does not exist, so treat this as unknown rather than absent — but if you are on it, you did not sign up for it deliberately.

Which leaves exactly one place where the news actually lives: github.com/n8n-io/n8n/security/advisories, opened by hand, by you, on purpose.

The field that exists to carry this news is empty

All of this was read from that endpoint on 8 September 2026. n8n ships a feature designed for precisely this. From its own environment-variable documentation:

N8N_VERSION_NOTIFICATIONS_ENABLED — When enabled, n8n sends notifications of new versions and security updates.

• Deployment environment variables, n8n documentation

It is on by default. It points at a public endpoint, and the records that endpoint returns carry three fields that could not be more explicitly designed for the job: hasSecurityIssue, hasSecurityFix and securityIssueFixVersion.

Here is one record, with two unrelated fields trimmed:

{"name":"2.37.10","createdAt":"2026-09-07T10:09:15.899Z","hasSecurityIssue":null,
 "hasSecurityFix":null,"securityIssueFixVersion":null,"hasBreakingChange":false,
 "description":"Includes <strong>core functionality</strong> and <strong>bug fixes</strong>"}

Seven running versions were queried, including 1.123.72 — a version with a published 8.7 host remote-code-execution advisory against it, fixed one patch release later. On all seven, across every record returned, those three fields were null.

Null means unpopulated, not "n8n asserts this is safe", and the difference is worth keeping straight. But the practical result is the same in both readings: the channel built to tell you about security updates is carrying no security updates, on every version tested, including versions with high-severity advisories filed against them.

There is a second finding hiding in the same endpoint, and it is the more actionable one. An instance running 1.123.72 is offered upgrade targets from 2.0.3 up to the newest 2.x on the day I looked — and is never offered 1.123.73, 1.123.76 or 1.123.77, the releases on its own major line that actually fix its vulnerabilities. The upgrade prompt's answer to a v1 instance carrying an 8.7 hole is a major-version migration.

Anyone who has read what the move to n8n 3 actually involves knows why that is not a small suggestion. The security debt and the migration debt get quietly welded together, and only one of them is your fault.

Cloud is patched for you, which is a different thing from safe

The obvious moral so far is that self-hosters are on their own, and they are. The self-hosted update page in the docs tells you to "keep your n8n version up to date to get the latest features and fixes", suggests you "try to update at least once a month", points at the release notes for breaking changes, and links to installation methods. That is the whole page. Its cadence is monthly against a fortnightly restock, the release notes it sends you to are the empty ones, and the words "security", "vulnerability" and "advisory" do not appear on it at all. The hardening guide for self-hosters lists seven measures — TLS at the reverse proxy, encryption at rest, blocking module imports in the Code node, isolating the instance — and staying patched is not one of them.

Cloud is the opposite. From the same documentation set:

The update cadence sets how often n8n upgrades your workspace to a newer build. n8n always applies security and stability updates automatically, whichever cadence you choose.

• Update your n8n version, n8n documentation

The recommended cadence there is described as "about every two weeks" — the same fortnightly rhythm as the advisory batches, which is not a coincidence. Cloud customers get patched on the vendor's schedule whether they read anything or not, and the restart that arrives with it is the price.

So the story should end with self-hosters exposed and Cloud customers protected. It does not, and the reason is the next section.

The header that stopped existing on 3 September

On 3 September, a customer opened an issue titled "Set-Cookie response headers are silently dropped from webhook responses". Their description:

Since 2026-09-03, a Respond to Webhook node no longer emits a Set-Cookie entry configured under Options → Response Headers. The header is dropped silently — no error, no warning, the execution is marked successful.

Other custom response headers from the same node are still emitted correctly. So this is specific to Set-Cookie; it is not "response headers stopped working" […]

This broke our OIDC/SSO login completely, in two separate projects on the same instance, at the same moment. Nothing on our side changed: the two workflows involved were last modified 2026-08-17 and 2026-08-27.

• the reporter, n8n issue #37773, 3 September 2026

Read the environment block they attached and the story turns over. platform: docker (cloud). n8nVersion: 2.37.7.

They were on Cloud. They did not choose to upgrade — the automatic security update quoted in the last section moved them onto 2.37.7, the release with the empty note, and that release is the one that stopped their logins working. Two workflows nobody had touched since August, broken at the same moment, by a change made for their own protection.

The only error anyone saw was downstream and misleading: ExpressionError: Invalid input for 'Token'. The header itself vanished without a sound. The reporter proved it cleanly by sending two headers at once — a made-up X-Probe and a Set-Cookie — and showing that the first arrived and the second did not, on two different response modes. A successful execution, a correct-looking response, one header short.

This is the same failure shape as an automation that tests green and fails live: every indicator you have says the run worked, because by the platform's definition it did.

"Wasn't part of normal release notes due to our process"

An n8n engineer answered the next day. Twenty-one hours after the report, which is fast; the automated bot that filed the internal ticket had answered in ten seconds, which is a nice illustration of what the modern support queue looks like. Her reply, verbatim:

Hi [...], thank you for reporting this. This is intentional, answer to your question 1 is: yes, and wasn't part of normal release notes due to our process around this. We're looking into a solution that allows opting into this safely.

[…] EDIT: will relax this in the next minor release so this use case won't need any changes, before designing a long term solution

• an n8n core platform engineer, on issue #37773, 4 September 2026

Three things in one comment. The change was deliberate. It was deliberately left out of the release notes. And it was reversed within a day of a customer noticing — the pull request that removes the block was opened and merged fifty minutes apart on 4 September, with a one-sentence description: "Webhook response headers block set-cookie. This drops the block, so a webhook response can set cookies again."

By the time you read this, that relaxation has almost certainly shipped and the issue is probably closed. The sequence is the part that keeps its shape:

1. 2 September. A security release goes out with an empty release note and, inside it, an unannounced change that blocks a response header.
2. 3 September. A Cloud customer's SSO stops working. No error, successful executions.
3. 4 September. The vendor confirms it was intentional and unannounced, offers a reverse-proxy workaround, then reverses the decision.

And here is the detail that makes it more than an anecdote. That change appears in no advisory — a search of all hundred advisories for cookies in the context of webhook responses returns nothing relevant. In no release note — zero hits across forty releases. In no findable commit message; the only commit in the repository's history matching the phrase is the one that undoes it. The sole public record that the change ever happened is a bug report from the customer it broke, and the reply underneath it.

How many people did this hit?

Honestly: one, that anyone can prove.

One reporter, two workflows, one instance. The n8n community forum had nothing when I looked on 8 September — searches for the header returned no posts after the change at all, and the nearest neighbours are people asking in July how to return two cookies at once, which at least establishes that this is a pattern real users build on.

That thin evidence is not a reason to shrug. A header that disappears without an error does not produce bug reports; it produces a login page that loops, a session that will not stick, and a support ticket in somebody else's inbox that says "the site is broken". The forum silence is the symptom, not the counter-evidence.

Which of these can actually reach you

Before doing anything, work out which of two situations you are in, because they lead to different sized jobs.

You self-host and you are the only user. Four of the five High advisories need a second person with editor rights, so they are not your exposure. The unauthenticated storage exhaustion is, and only if you are on the 2.x line with a publicly reachable instance — which you are, if you receive webhooks from anywhere. A Cloudflare tunnel does not help here, because the registration endpoint sits on the same HTTP surface as the webhooks you deliberately exposed. n8n's own suggested mitigation is one you already own: a body-size limit at the reverse proxy, below the default 16 MiB.

You self-host with a team, or you share workflows with clients. Then the expression sandbox escapes are live for you, and the phrase in the advisory to note is that an expression could run "in the session of whoever opened the workflow". The threat model is not a stranger on the internet. It is anyone you gave edit rights to, including the contractor who built the thing two years ago and still has a login.

You are on Cloud. The vulnerabilities are handled without you. What is not handled is the other half — you are on the receiving end of a fortnightly forced upgrade whose release notes are empty, which is exactly how September went for the person in that issue.

Making this a habit rather than a project

The instinct after reading all this is to do a security audit. Resist it; a one-off audit is worth less here than a five-minute routine, because the restock date is never more than fourteen days away.

1. Find out which line you are on. 1.x, 2.x stable, or 2.x beta. The advisories list affected versions per line, and several recent ones affect only 2.x. Without this number nothing else in the list means anything.
2. Bookmark the one page that carries the news — the repository's security advisories — and look at it on a schedule. Fortnightly matches the cadence. There is no feed to subscribe to, so a recurring calendar entry is genuinely the state of the art.
3. Do not rely on npm audit, Dependabot or a container scanner for this. With no CVEs assigned and a database that trailed by six weeks in September, a clean report is not evidence of anything.
4. Put the body-size limit on the reverse proxy if you are on 2.x and take webhooks from the internet. This is the one mitigation you can apply without an upgrade, and n8n lists it as a short-term measure rather than a remedy. 16 MiB is the number to go below.
5. Read the advisory workarounds before assuming you must upgrade today. Several list a configuration change that holds the hole shut — restricting who can author expressions, or switching the expression engine — which n8n describes as short-term mitigation rather than a fix, and which buys you a scheduled maintenance window instead of an emergency one.
6. When you do upgrade, check the things nobody promised to keep working. An empty release note is not a promise that nothing changed. If your webhooks return headers, set cookies, or feed a login flow, exercise one after the upgrade rather than trusting the green tick on the execution list.
7. Watch executions for success-shaped failures. The September breakage produced successful runs, so an alert on failed executions would never have fired. This is the same reason somebody has to be watching the outputs, not the status column.

When this is a job to hand over

This is the rare one where there is no fix to buy, because the thing that is broken is not in your instance. What somebody would be selling you here is a routine: read the batch when it lands, work out whether any of it reaches your deployment, decide whether it waits for the maintenance window, and exercise the workflows that face the outside world after the upgrade. That is a standing arrangement, not a repair, and it should be described that way before anyone quotes it.

The discrete piece of work sitting next to it is a different question — not "am I vulnerable" but "what would break if I upgraded". For an instance nobody has touched in a year, the gap to the current version contains a major migration, and the number that sizes it is how many workflows use the nodes that changed. For an agency, the number is instances, and what it buys is one person reading one page a fortnight instead of nobody reading it ever. Either way it starts as an inventory, and most of the n8n work we take begins with somebody unable to say which version they are running.

Patch promptly and something might break quietly. Do not patch and something is already broken quietly. There is no version of this where you get to not be paying attention.

Sources

• n8n repository security advisories - read through the GitHub API on 8 September 2026, the 100 most recent records. The fortnightly publication cadence from 13 May to 3 September, the severity breakdown per batch, a CVE identifier on twenty-one of the hundred records and none at all on anything published since 5 August, and the verbatim descriptions and affected version ranges for the five High advisories of 2 September.
• GHSA-hh89-3r9w-qj3j, GHSA-hw8v-xxg5-vvvx, GHSA-6xcw-7xm6-48c6, GHSA-34ff-336r-5q23, GHSA-j535-v25q-vx3q - n8n, published 2 September 2026. The CVSS 4.0 vectors used to work out what each one needs from an attacker, the vendor's listed workarounds including the reverse-proxy body-size limit, and the note that the vulnerable blocked-file-pattern was the shipped default.
• n8n@2.37.7 release and n8n@1.123.76 release - read 8 September 2026. The empty release note on the stable line, and the single changelog line on the v1 line naming a dependency's CVE.
• n8n releases - read through the API on 8 September 2026, 300 records. The publication times showing the fixes shipped hours before the advisories, and the absence of any mention of cookies across the forty most recent release bodies.
• GitHub Advisory Database and OSV - queried through their APIs on 8 September 2026 for the npm package n8n. The newest record in each was published 22 July 2026, and 45 of the repository's 100 advisories were absent, corresponding exactly to the August and September batches. Direct lookups of the September advisories returned not-found from both.
• n8n docs release notes - read 8 September 2026 from the documentation source. Described as a log of feature-level updates, with no entry for the security patch releases and no occurrence of "vulnerability", "advisory", "CVE" or "GHSA".
• Deployment environment variables - n8n documentation, read 8 September 2026. The description of N8N_VERSION_NOTIFICATIONS_ENABLED as covering security updates, and the public endpoint it points at.
• n8n version notification endpoint, api.n8n.io/api/versions/ - queried 8 September 2026 for seven running versions including 1.123.72, 2.33.4, 2.37.6 and 2.37.7. Every record returned null for hasSecurityIssue, hasSecurityFix and securityIssueFixVersion, and no v1 instance was offered a patched v1 release as an upgrade target.
• Update your n8n version and Update self-hosted n8n - n8n documentation, read 8 September 2026. The automatic security updates on Cloud regardless of chosen cadence, the roughly fortnightly recommended cadence, and by contrast the self-hosted page's monthly suggestion, with the words security, vulnerability and advisory absent from it entirely.
• Security guidance for self-hosted instances - n8n documentation, read 8 September 2026. Seven hardening measures listed for self-hosted users, none of which is staying patched, and no mention of the advisories.
• n8n issue #37773 - read through the GitHub API on 8 September 2026. The report of Set-Cookie being dropped from webhook responses, the reporter's environment block showing Cloud and version 2.37.7, the two-header probe, the downstream expression error, and the n8n engineer's confirmation that the change was intentional and deliberately outside the release notes.
• n8n pull request #37883 - read through the GitHub API on 8 September 2026. Opened and merged on 4 September, removing the block, with the vendor's own one-sentence description of what the block was.
• community.n8n.io - searched 8 September 2026. No posts about the dropped header after 3 September, and earlier threads from March and July 2026 establishing that cookie-setting webhook responses are a pattern users build on.