GHSA-hv7x-3x78-gx53: n8n auth bypass lets read-only

Q: Is GHSA-hv7x-3x78-gx53 actively exploited?

No confirmed active exploitation of GHSA-hv7x-3x78-gx53 has been reported, but organizations should still patch proactively.

Q: How to fix GHSA-hv7x-3x78-gx53?

1. Patch: upgrade n8n to 1.123.55 (v1 branch), 2.25.7, or 2.26.2 immediately—all three branches are fixed. 2. Interim workaround if patching is delayed: audit all project role assignments and ensure `workflow:read` on sensitive workflows is granted only to users who also hold `workflow:execute`. 3. Consider temporarily disabling the Evaluations feature via admin settings if it is not actively in use. 4. Detection: review application access logs for unexpected POST requests to /workflows/{workflowId}/test-runs/new from accounts with read-only roles. 5. Monitor downstream systems—LLM API usage dashboards, database write logs, connected webhook endpoints—for anomalous activity patterns consistent with unauthorized workflow execution.

Q: What systems are affected by GHSA-hv7x-3x78-gx53?

This vulnerability affects the following AI/ML architecture patterns: AI agent frameworks, Workflow automation pipelines, LLM integration pipelines, Multi-step agentic systems.

Q: What is the CVSS score for GHSA-hv7x-3x78-gx53?

GHSA-hv7x-3x78-gx53 has a CVSS v3.1 base score of 7.4 (HIGH).

CISO Take

n8n, the AI workflow automation platform widely used to orchestrate LLM calls, API integrations, and multi-step agentic pipelines, contains an authorization flaw in its Evaluations feature: any authenticated user with `workflow:read` access can trigger real workflow execution test runs that should require `workflow:execute` permission. In enterprise RBAC deployments—where contractors, auditors, or lower-privileged staff commonly hold read-only access to sensitive workflows—this allows unauthorized actors to silently trigger outbound API calls, database mutations, or cascading AI agent actions without detection. No public exploit exists and this is not in CISA KEV, but the attack bar is trivially low (valid low-privilege account plus a single HTTP POST), and the CVSS scope change (S:C, score 7.4) reflects that downstream systems connected to the workflow—LLM APIs, databases, webhooks—are impacted beyond n8n itself. Patch immediately to n8n 1.123.55, 2.25.7, or 2.26.2; if patching is delayed, audit project role assignments and restrict `workflow:read` on sensitive workflows to users who also hold `workflow:execute`, then review logs for unexpected POST activity on /workflows/{workflowId}/test-runs/new.

Sources: GitHub Advisory ATLAS OpenSSF

What is the risk?

High risk (CVSS 7.4, S:C). The attack requires only a valid low-privilege authenticated account and a single crafted HTTP request—no AI or ML expertise needed. The scope change to downstream systems is the critical differentiator: in AI pipeline contexts, connected LLM APIs, databases, and webhooks bear the actual blast radius. With 95 prior CVEs in the n8n package and an OpenSSF score of only 6.5/10, the security maturity of this codebase warrants elevated vigilance. RBAC-enabled enterprise deployments are the highest-exposure population; single-user or fully trusted deployments have minimal exposure.

How does the attack unfold?

Initial Access

Attacker authenticates to n8n with a valid low-privilege account holding `workflow:read` on a targeted sensitive workflow.

AML.T0012

Exploitation

Attacker sends a crafted POST to /workflows/{workflowId}/test-runs/new; the endpoint validates `workflow:read` instead of `workflow:execute`, granting unauthorized execution rights.

AML.T0049

Execution

n8n's internal workflow runner executes the full workflow in a live (non-sandboxed) context, invoking connected tools including LLM APIs, database write connectors, and external webhooks.

AML.T0053

Impact

Downstream systems incur unintended side effects: LLM API calls are billed to the victim, databases are mutated with attacker-triggered data, and sensitive workflow outputs propagate to connected services.

AML.T0048

Initial Access

Attacker authenticates to n8n with a valid low-privilege account holding `workflow:read` on a targeted sensitive workflow.

AML.T0012

Exploitation

Attacker sends a crafted POST to /workflows/{workflowId}/test-runs/new; the endpoint validates `workflow:read` instead of `workflow:execute`, granting unauthorized execution rights.

AML.T0049

Execution

n8n's internal workflow runner executes the full workflow in a live (non-sandboxed) context, invoking connected tools including LLM APIs, database write connectors, and external webhooks.

AML.T0053

Impact

Downstream systems incur unintended side effects: LLM API calls are billed to the victim, databases are mutated with attacker-triggered data, and sensitive workflow outputs propagate to connected services.

AML.T0048

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
n8n	npm	< 1.123.55	`1.123.55`
192.4K OpenSSF 6.5 Pushed 2d ago 51% patched ~3d to patch Full package profile →

Do you use n8n? You're affected.

How severe is it?

CVSS 3.1

7.4 / 10

EPSS

N/A

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 Low

What should I do?

5 steps

Patch: upgrade n8n to 1.123.55 (v1 branch), 2.25.7, or 2.26.2 immediately—all three branches are fixed.
Interim workaround if patching is delayed: audit all project role assignments and ensure workflow:read on sensitive workflows is granted only to users who also hold workflow:execute.
Consider temporarily disabling the Evaluations feature via admin settings if it is not actively in use.
Detection: review application access logs for unexpected POST requests to /workflows/{workflowId}/test-runs/new from accounts with read-only roles.
Monitor downstream systems—LLM API usage dashboards, database write logs, connected webhook endpoints—for anomalous activity patterns consistent with unauthorized workflow execution.

How is it classified?

Auth Bypass Code Execution Agent Framework AML.T0012 - Valid Accounts AML.T0034.002 - Agentic Resource Consumption AML.T0049 - Exploit Public-Facing Application AML.T0053 - AI Agent Tool Invocation

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 9 - Risk management system

ISO 42001

A.6.1.4 - AI system access control

NIST AI RMF

GOVERN 1.7 - Processes for tracking and managing AI risks

OWASP LLM Top 10

LLM08 - Excessive Agency

Frequently Asked Questions

What is GHSA-hv7x-3x78-gx53?

n8n, the AI workflow automation platform widely used to orchestrate LLM calls, API integrations, and multi-step agentic pipelines, contains an authorization flaw in its Evaluations feature: any authenticated user with `workflow:read` access can trigger real workflow execution test runs that should require `workflow:execute` permission. In enterprise RBAC deployments—where contractors, auditors, or lower-privileged staff commonly hold read-only access to sensitive workflows—this allows unauthorized actors to silently trigger outbound API calls, database mutations, or cascading AI agent actions without detection. No public exploit exists and this is not in CISA KEV, but the attack bar is trivially low (valid low-privilege account plus a single HTTP POST), and the CVSS scope change (S:C, score 7.4) reflects that downstream systems connected to the workflow—LLM APIs, databases, webhooks—are impacted beyond n8n itself. Patch immediately to n8n 1.123.55, 2.25.7, or 2.26.2; if patching is delayed, audit project role assignments and restrict `workflow:read` on sensitive workflows to users who also hold `workflow:execute`, then review logs for unexpected POST activity on /workflows/{workflowId}/test-runs/new.

Is GHSA-hv7x-3x78-gx53 actively exploited?

No confirmed active exploitation of GHSA-hv7x-3x78-gx53 has been reported, but organizations should still patch proactively.

How to fix GHSA-hv7x-3x78-gx53?

1. Patch: upgrade n8n to 1.123.55 (v1 branch), 2.25.7, or 2.26.2 immediately—all three branches are fixed. 2. Interim workaround if patching is delayed: audit all project role assignments and ensure `workflow:read` on sensitive workflows is granted only to users who also hold `workflow:execute`. 3. Consider temporarily disabling the Evaluations feature via admin settings if it is not actively in use. 4. Detection: review application access logs for unexpected POST requests to /workflows/{workflowId}/test-runs/new from accounts with read-only roles. 5. Monitor downstream systems—LLM API usage dashboards, database write logs, connected webhook endpoints—for anomalous activity patterns consistent with unauthorized workflow execution.

What systems are affected by GHSA-hv7x-3x78-gx53?

This vulnerability affects the following AI/ML architecture patterns: AI agent frameworks, Workflow automation pipelines, LLM integration pipelines, Multi-step agentic systems.

What is the CVSS score for GHSA-hv7x-3x78-gx53?

GHSA-hv7x-3x78-gx53 has a CVSS v3.1 base score of 7.4 (HIGH).

What is the AI security impact?

Affected AI Architectures

AI agent frameworksWorkflow automation pipelinesLLM integration pipelinesMulti-step agentic systems

MITRE ATLAS Techniques

AML.T0012 Valid Accounts

AML.T0034.002 Agentic Resource Consumption

AML.T0049 Exploit Public-Facing Application

AML.T0053 AI Agent Tool Invocation

Compliance Controls Affected

EU AI Act: Article 9

ISO 42001: A.6.1.4

NIST AI RMF: GOVERN 1.7

OWASP LLM Top 10: LLM08

What are the technical details?

Original Advisory

## Impact The `POST /workflows/{workflowId}/test-runs/new` endpoint authorized access using `workflow:read` rather than `workflow:execute`. An authenticated user with read-only access to a workflow could trigger a real evaluation test run, causing the workflow to execute via the internal workflow runner. This could result in unintended outbound API calls, data mutations, or other side effects in downstream systems connected to the workflow. This issue primarily affects instances where the Evaluations feature is in use and where users may have `workflow:read` access without `workflow:execute` access, such as deployments using RBAC project roles. ## Patches The issue has been fixed in n8n versions 1.123.55, 2.25.7, and 2.26.2. Users should upgrade to one of these versions or later to remediate the vulnerability. ## Workarounds If upgrading is not immediately possible, administrators should consider the following temporary mitigations: - Restrict workflow access to fully trusted users only. - Audit project role assignments and limit `workflow:read` access on sensitive workflows to users who should also be permitted to execute them. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

Exploitation Scenario

A contractor with legitimate read-only access to a production n8n workspace identifies or infers the Evaluations test-run endpoint. They craft a POST request to /workflows/{workflowId}/test-runs/new targeting a workflow that orchestrates GPT-4 calls for data enrichment, writes results to a PostgreSQL database, and pushes notifications to internal Slack channels. The authorization check incorrectly validates only `workflow:read`—which the contractor holds—rather than `workflow:execute`. The internal runner executes the full pipeline: LLM API calls are billed to the organization, the database is written with potentially polluted data, and internal Slack channels receive unexpected messages. By enumerating accessible workflow IDs, the attacker can trigger repeated executions across multiple sensitive pipelines, escalating cost impact and data contamination in AI processing chains.

Weaknesses (CWE)

CWE-284 Improper Access Control Primary

CWE-284 — Improper Access Control: The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.

[Architecture and Design, Operation] Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
[Architecture and Design] Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.

Source: MITRE CWE corpus.