n8n stable patch 2.45.7 enforces execution:read on workflow-scoped routes

n8n shipped patch releases for all three of its maintained branches on 30 October — 2.46.3 on the beta line, 2.45.7 on stable and 1.123.91 on the legacy 1.x series — according to a dev.to summary of the project's GitHub release notes. Only the stable build contains a hardening fix; the beta and legacy builds from the same day are described as routine maintenance.

The authorization tightening in 2.45.7

The changelog for 2.45.7 lists a core fix: routes scoped to a workflow now demand the execution:read scope before they will serve execution data. As the dev.to post explains, those routes could previously hand execution data to users whose roles covered workflow scopes but not execution scopes. The dedicated executions API has always applied the execution:read check, and this patch aligns the workflow-scoped routes with it.

A related change, merged on 23 October, extends the same rule to n8n's AI Assistant, which now needs execution:read to read and list executions and to pull recent runs into its context — matching the executions API and the project's MCP tools. The report points to pull request 41863 and merge commit a967486 as the record of the change.

No security advisory yet

As of publication, no GitHub security advisory specific to this change appears in n8n's public advisories listing, which currently shows only unrelated items from a 28 October security update, according to the dev.to post. The project generally announces security-relevant changes through its regular GitHub releases and fortnightly security posts on the community forum, where advisories carry GHSA identifiers.

Signed invitation tokens on the legacy line

The legacy branch picked up a security-adjacent change a day earlier. Release 1.123.90, shipped on 29 October, made a signed token mandatory for accepting invitations, so unsigned invite links no longer work. The execution:read tightening, however, has not appeared in any 1.123.x release so far, the report notes.

What operators should do

The dev.to post advises self-hosted operators and platform teams to plan an upgrade to 2.45.7, where the fix currently ships, and flags two follow-up tasks:

• Audit custom roles and project permissions. Roles that grant workflow scopes without execution:read will stop receiving execution data from workflow-scoped routes, so dashboards, reports or integrations that leaned on the old behavior need the execution:read scope added explicitly.
• Reissue outstanding invitation links, since older unsigned ones will no longer be accepted.

Users on all branches should move to the respective patch versions, the post adds.

Why it matters

This is a least-privilege fix in software that teams self-host and wire into their wider infrastructure. Gaps like this one — where a primary API enforces a permission but a scoped variant quietly does not — are a classic blind spot, and they can persist for a long time because nothing obviously breaks. For operators the exposure cuts both ways: execution data was reachable through a path that bypassed the intended permission model, and once the patch lands, tooling that silently depended on the looser behavior will start failing. The fact that the tightening has not reached the 1.x line yet is also worth factoring in for anyone still running legacy versions and weighing how urgently to upgrade.