CVE-2026-56778: n8n workflow:read scope triggers

CISO Take

n8n's Public API checks the workflow:read scope instead of workflow:execute on its execution-retry endpoint, so any authenticated user who has been granted read-only access to a shared workflow can silently trigger that workflow to run again via the API. n8n workflows are widely used as no-code AI agent orchestrators, meaning a 'read-only' collaborator could re-trigger flows that call LLM APIs, write to databases, send emails, or invoke other agent tools — actions the sharing model was explicitly designed to prevent them from taking. There is no CISA KEV listing, no EPSS score, and no public exploit or Nuclei template yet, so this looks opportunistic rather than actively exploited, but the flaw sits in a package with a track record of 123 other CVEs and a middling OpenSSF Scorecard of 6.6/10, so scrutiny of its permission model is warranted. Confidentiality and integrity impact are limited (CVSS 6.4, C:L/I:L/A:N) since this is about unauthorized re-execution rather than data exfiltration or full compromise, but any instance sharing workflows across users or projects should audit who has read access before assuming it's harmless. Patch to n8n 2.25.7 or 2.26.2+ immediately, and until then treat 'read' access as equivalent to 'execute' access when deciding who to share workflows with.

Sources: NVD GitHub Advisory VulnCheck OpenSSF ATLAS

What is the risk?

Medium severity (CVSS 6.4): network-exploitable, low attack complexity, no user interaction, but requires the attacker to already hold a valid authenticated account with workflow:read access shared to the target workflow — this is a privilege-boundary escalation, not remote unauthenticated compromise. No CISA KEV listing, no EPSS score, and no public exploit or Nuclei template exist, indicating low current exploitation pressure. Impact is bounded (C:L/I:L/A:N) — the attacker can force re-execution but cannot directly read data or crash the system. Real-world risk scales with how broadly an organization shares n8n workflows across users/projects: multi-tenant or team deployments that grant 'read-only' or 'auditor' roles are most exposed, since this bug quietly collapses the read/execute boundary those roles depend on.

How does the attack unfold?

Initial Access

Attacker authenticates with a legitimate account holding only workflow:read access to a workflow shared across users or projects.

AML.T0012

Discovery

Attacker identifies the Public API's execution-retry endpoint and confirms it accepts requests from a workflow:read-scoped key.

AML.T0006

Exploitation

Attacker calls the execution-retry endpoint, which authorizes on workflow:read instead of workflow:execute, triggering a full re-run of the workflow's nodes.

AML.T0053

Impact

Re-execution repeats side effects such as LLM calls, database writes, emails, or webhook actions the attacker was never authorized to trigger, incurring cost and potential integrity issues.

Initial Access

Attacker authenticates with a legitimate account holding only workflow:read access to a workflow shared across users or projects.

AML.T0012

Discovery

Attacker identifies the Public API's execution-retry endpoint and confirms it accepts requests from a workflow:read-scoped key.

AML.T0006

Exploitation

Attacker calls the execution-retry endpoint, which authorizes on workflow:read instead of workflow:execute, triggering a full re-run of the workflow's nodes.

AML.T0053

Impact

Re-execution repeats side effects such as LLM calls, database writes, emails, or webhook actions the attacker was never authorized to trigger, incurring cost and potential integrity issues.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
n8n	npm	—	No patch
201.9K OpenSSF 6.7 Pushed today 51% patched ~6d to patch Full package profile →

Do you use n8n? You're affected.

How severe is it?

CVSS 3.1

6.4 / 10

EPSS

0.2%

chance of exploitation in 30 days

Higher than 7% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AV Network

AC Low

PR Low

UI None

S Changed

C Low

I Low

A None

What should I do?

1 step

Upgrade immediately to n8n 2.25.7+ (2.25.x branch) or 2.26.2+ (2.26.x branch). Until patched, audit workflow sharing settings and treat any user or project with read access to a workflow as functionally able to execute it — restrict sharing to only those who legitimately need execute rights. Review Public API access logs for execution-retry calls made by API keys scoped only to workflow:read, especially where the associated account lacks an execute grant. Rotate and narrowly scope Public API keys, and consider temporarily disabling cross-user/cross-project workflow sharing for sensitive automations until upgraded. Cross-reference n8n audit logs of retry-execution calls against role assignments to detect anomalous invocations.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Auth Bypass Agent API AML.T0012 - Valid Accounts AML.T0053 - AI Agent Tool Invocation

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

OWASP LLM Top 10

LLM06:2025 - Excessive Agency

Frequently Asked Questions

What is CVE-2026-56778?

n8n's Public API checks the workflow:read scope instead of workflow:execute on its execution-retry endpoint, so any authenticated user who has been granted read-only access to a shared workflow can silently trigger that workflow to run again via the API. n8n workflows are widely used as no-code AI agent orchestrators, meaning a 'read-only' collaborator could re-trigger flows that call LLM APIs, write to databases, send emails, or invoke other agent tools — actions the sharing model was explicitly designed to prevent them from taking. There is no CISA KEV listing, no EPSS score, and no public exploit or Nuclei template yet, so this looks opportunistic rather than actively exploited, but the flaw sits in a package with a track record of 123 other CVEs and a middling OpenSSF Scorecard of 6.6/10, so scrutiny of its permission model is warranted. Confidentiality and integrity impact are limited (CVSS 6.4, C:L/I:L/A:N) since this is about unauthorized re-execution rather than data exfiltration or full compromise, but any instance sharing workflows across users or projects should audit who has read access before assuming it's harmless. Patch to n8n 2.25.7 or 2.26.2+ immediately, and until then treat 'read' access as equivalent to 'execute' access when deciding who to share workflows with.

Is CVE-2026-56778 actively exploited?

No confirmed active exploitation of CVE-2026-56778 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-56778?

Upgrade immediately to n8n 2.25.7+ (2.25.x branch) or 2.26.2+ (2.26.x branch). Until patched, audit workflow sharing settings and treat any user or project with read access to a workflow as functionally able to execute it — restrict sharing to only those who legitimately need execute rights. Review Public API access logs for execution-retry calls made by API keys scoped only to workflow:read, especially where the associated account lacks an execute grant. Rotate and narrowly scope Public API keys, and consider temporarily disabling cross-user/cross-project workflow sharing for sensitive automations until upgraded. Cross-reference n8n audit logs of retry-execution calls against role assignments to detect anomalous invocations.

What systems are affected by CVE-2026-56778?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow orchestration pipelines, third-party integration pipelines.

What is the CVSS score for CVE-2026-56778?

CVE-2026-56778 has a CVSS v3.1 base score of 6.4 (MEDIUM). The EPSS exploitation probability is 0.17%.

What is the AI security impact?

Affected AI Architectures

agent frameworksworkflow orchestration pipelinesthird-party integration pipelines

MITRE ATLAS Techniques

AML.T0012 Valid Accounts

AML.T0053 AI Agent Tool Invocation

Compliance Controls Affected

EU AI Act: Article 15

OWASP LLM Top 10: LLM06:2025

What are the technical details?

Original Advisory

n8n before 2.25.7 and 2.26.x before 2.26.2 contains an authorization bypass in the Public API execution retry endpoint, which authorizes access using the workflow:read scope instead of workflow:execute. An authenticated user with read-only access to a shared workflow can use the Public API to retry executions of that workflow, bypassing the intended permission boundary between read and execute access. This affects instances where workflows are shared with other users or across projects.

Exploitation Scenario

An organization uses n8n to orchestrate an AI agent pipeline — e.g., CRM enrichment feeding an LLM summarization step plus outbound email notifications. A compliance analyst is granted read-only access to the workflow so they can review its logic, on the assumption they cannot trigger real executions. Using their existing Public API key (scoped to workflow:read) — or an attacker who compromises that low-privilege key — the analyst calls the execution-retry endpoint for a prior run. Because the endpoint authorizes on workflow:read instead of workflow:execute, the request succeeds: LLM calls fire again (incurring cost and potential data exposure), outbound emails or webhook side effects repeat, and any downstream database or vector-store writes are duplicated — all without the caller ever holding execute privileges.

Weaknesses (CWE)

CWE-863 Incorrect Authorization CWE-863 Incorrect Authorization

CWE-863 — Incorrect Authorization: The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.

[Architecture and Design] Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
[Architecture and Design] Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Source: MITRE CWE corpus.