GHSA-h3jj-5f3v-3685: n8n read-only users can

Q: Is GHSA-h3jj-5f3v-3685 actively exploited?

No confirmed active exploitation of GHSA-h3jj-5f3v-3685 has been reported, but organizations should still patch proactively.

Q: How to fix GHSA-h3jj-5f3v-3685?

1. **Patch immediately**: Upgrade to n8n 2.25.7 or 2.26.2. These versions correctly gate the retry-execution endpoint on `workflow:execute`. 2. **Audit shared workflows**: Run `GET /api/v1/workflows` and identify all workflows with `shareWith` entries or cross-project visibility — these are the exploitable surface. 3. **Restrict sharing as interim control**: Remove read access from untrusted users on workflows that invoke sensitive operations until patching is complete. 4. **Network-layer control**: If Public API exposure cannot be eliminated, restrict it to trusted IP ranges via firewall or reverse proxy ACL. 5. **Detection**: Review n8n execution logs for retry-endpoint calls (`POST /api/v1/executions/{id}/retry`) originating from accounts with only `workflow:read` grants — these indicate exploitation attempts. 6. **Post-patch**: Re-audit workflow sharing policies; enforce least-privilege as a standing control.

Q: What systems are affected by GHSA-h3jj-5f3v-3685?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow automation pipelines, LLM orchestration layers, multi-tenant AI platforms.

Q: What is the CVSS score for GHSA-h3jj-5f3v-3685?

GHSA-h3jj-5f3v-3685 has a CVSS v3.1 base score of 6.4 (MEDIUM).

CISO Take

n8n's Public API incorrectly validates the retry-execution endpoint against `workflow:read` instead of `workflow:execute`, allowing any authenticated user with read-only access to a shared workflow to trigger its execution on demand. In enterprise and team deployments where workflows are shared across projects — common in AI agent orchestration stacks — this breaks the separation of duty between viewers and operators, enabling unauthorized actors to fire off pipelines that interact with databases, external APIs, or downstream AI services. The CVSS Scope is Changed (S:C), meaning the blast radius extends beyond n8n itself to whatever systems the workflows touch. No public exploit exists and EPSS data is unavailable, but the attack requires only a valid API token with read access, making it trivially reproducible by any malicious insider or compromised low-privilege account. Upgrade to n8n 2.25.7 or 2.26.2 immediately; if upgrading is not possible, lock workflow sharing to fully trusted users and restrict Public API network access.

Sources: GitHub Advisory ATLAS OpenSSF

What is the risk?

Medium CVSS (6.4) understates real-world risk in AI agent contexts. n8n is widely deployed as a no-code orchestration layer for AI pipelines — integrating LLMs, vector databases, and external services. The permission bypass is low-complexity (AV:N/AC:L/PR:L/UI:N) and requires only an authenticated session with read access, which is a common grant in collaborative environments. The Changed scope amplifies impact: a workflow that calls an LLM API, writes to a database, or invokes a webhook can cause harm far beyond n8n's own boundary. With 105 prior CVEs in this package and an OpenSSF score of 6.5/10, the codebase has a non-trivial security surface. The absence of a public exploit and KEV listing keeps this at medium operational priority, but teams running shared n8n deployments should treat patching as urgent.

How does the attack unfold?

Credential Acquisition

Attacker obtains a legitimate n8n API token with `workflow:read` permission — through account creation, insider access, or credential theft — granting visibility into shared workflows.

AML.T0012

API Exploitation

Attacker sends a POST request to the Public API retry endpoint (`/api/v1/executions/{id}/retry`) using the read-only token; the endpoint incorrectly checks `workflow:read` and grants execution.

AML.T0049

Unauthorized Tool Invocation

The workflow executes in full, invoking all its configured steps: LLM API calls, database operations, webhook triggers, or external service integrations — beyond the attacker's intended authorization.

AML.T0053

Impact

Downstream effects materialize: API quota exhaustion, duplicate or corrupted data in connected systems, unauthorized external notifications, or repeated sensitive operations that cause financial or operational harm.

AML.T0048

Credential Acquisition

Attacker obtains a legitimate n8n API token with `workflow:read` permission — through account creation, insider access, or credential theft — granting visibility into shared workflows.

AML.T0012

API Exploitation

Attacker sends a POST request to the Public API retry endpoint (`/api/v1/executions/{id}/retry`) using the read-only token; the endpoint incorrectly checks `workflow:read` and grants execution.

AML.T0049

Unauthorized Tool Invocation

The workflow executes in full, invoking all its configured steps: LLM API calls, database operations, webhook triggers, or external service integrations — beyond the attacker's intended authorization.

AML.T0053

Impact

Downstream effects materialize: API quota exhaustion, duplicate or corrupted data in connected systems, unauthorized external notifications, or repeated sensitive operations that cause financial or operational harm.

AML.T0048

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
n8n	npm	>= 2.26.0, < 2.26.2	`2.26.2`
192.4K OpenSSF 6.5 Pushed 3d ago 55% patched ~2d to patch Full package profile →

Do you use n8n? You're affected.

How severe is it?

CVSS 3.1

6.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 None

What should I do?

6 steps

Patch immediately

Upgrade to n8n 2.25.7 or 2.26.2. These versions correctly gate the retry-execution endpoint on workflow:execute.
Audit shared workflows

Run GET /api/v1/workflows and identify all workflows with shareWith entries or cross-project visibility — these are the exploitable surface.
Restrict sharing as interim control

Remove read access from untrusted users on workflows that invoke sensitive operations until patching is complete.
Network-layer control

If Public API exposure cannot be eliminated, restrict it to trusted IP ranges via firewall or reverse proxy ACL.
Detection

Review n8n execution logs for retry-endpoint calls (POST /api/v1/executions/{id}/retry) originating from accounts with only workflow:read grants — these indicate exploitation attempts.
Post-patch

Re-audit workflow sharing policies; enforce least-privilege as a standing control.

How is it classified?

Auth Bypass Agent AML.T0012 - Valid Accounts 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.2.3 - Access control

NIST AI RMF

GOVERN 1.2 - Policies, processes and procedures for AI risk management

OWASP LLM Top 10

LLM08 - Excessive Agency

Frequently Asked Questions

What is GHSA-h3jj-5f3v-3685?

n8n's Public API incorrectly validates the retry-execution endpoint against `workflow:read` instead of `workflow:execute`, allowing any authenticated user with read-only access to a shared workflow to trigger its execution on demand. In enterprise and team deployments where workflows are shared across projects — common in AI agent orchestration stacks — this breaks the separation of duty between viewers and operators, enabling unauthorized actors to fire off pipelines that interact with databases, external APIs, or downstream AI services. The CVSS Scope is Changed (S:C), meaning the blast radius extends beyond n8n itself to whatever systems the workflows touch. No public exploit exists and EPSS data is unavailable, but the attack requires only a valid API token with read access, making it trivially reproducible by any malicious insider or compromised low-privilege account. Upgrade to n8n 2.25.7 or 2.26.2 immediately; if upgrading is not possible, lock workflow sharing to fully trusted users and restrict Public API network access.

Is GHSA-h3jj-5f3v-3685 actively exploited?

No confirmed active exploitation of GHSA-h3jj-5f3v-3685 has been reported, but organizations should still patch proactively.

How to fix GHSA-h3jj-5f3v-3685?

1. **Patch immediately**: Upgrade to n8n 2.25.7 or 2.26.2. These versions correctly gate the retry-execution endpoint on `workflow:execute`. 2. **Audit shared workflows**: Run `GET /api/v1/workflows` and identify all workflows with `shareWith` entries or cross-project visibility — these are the exploitable surface. 3. **Restrict sharing as interim control**: Remove read access from untrusted users on workflows that invoke sensitive operations until patching is complete. 4. **Network-layer control**: If Public API exposure cannot be eliminated, restrict it to trusted IP ranges via firewall or reverse proxy ACL. 5. **Detection**: Review n8n execution logs for retry-endpoint calls (`POST /api/v1/executions/{id}/retry`) originating from accounts with only `workflow:read` grants — these indicate exploitation attempts. 6. **Post-patch**: Re-audit workflow sharing policies; enforce least-privilege as a standing control.

What systems are affected by GHSA-h3jj-5f3v-3685?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow automation pipelines, LLM orchestration layers, multi-tenant AI platforms.

What is the CVSS score for GHSA-h3jj-5f3v-3685?

GHSA-h3jj-5f3v-3685 has a CVSS v3.1 base score of 6.4 (MEDIUM).

What is the AI security impact?

Affected AI Architectures

agent frameworksworkflow automation pipelinesLLM orchestration layersmulti-tenant AI platforms

MITRE ATLAS Techniques

AML.T0012 Valid Accounts

AML.T0049 Exploit Public-Facing Application

AML.T0053 AI Agent Tool Invocation

Compliance Controls Affected

EU AI Act: Article 9

ISO 42001: A.6.2.3

NIST AI RMF: GOVERN 1.2

OWASP LLM Top 10: LLM08

What are the technical details?

Original Advisory

## Impact The Public API endpoint for retrying executions authorized access using `workflow:read` rather than `workflow:execute`. An authenticated user with read-only access to a shared workflow could use the Public API to retry executions of that workflow, bypassing the intended permission boundary between read and execute access. This issue affects instances where workflows are shared with other users or across projects. ## Patches The issue has been fixed in n8n versions 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 sharing to fully trusted users only. - Restrict network access to the n8n Public API to trusted users only. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

Exploitation Scenario

An analyst at a company is granted read-only access to an n8n workflow that daily ingests threat intelligence feeds, calls an OpenAI GPT-4 API to summarize reports, and stores results in a production PostgreSQL database. After discovering the permission boundary bug (e.g., from the public advisory), the analyst crafts a POST request to `/api/v1/executions/{recent_execution_id}/retry` using their existing API token. The endpoint accepts the request without checking `workflow:execute` permission. The workflow fires: the OpenAI API is called (burning quota), the database receives duplicate or malformed writes, and if the workflow has outbound webhook steps, external notifications or alerts are sent. A malicious insider could loop this call to exhaust API rate limits, corrupt the database state, or trigger downstream security tooling with fabricated data — all while appearing as a legitimate execution in audit logs attributed to the workflow's original owner.

Weaknesses (CWE)

CWE-863 Incorrect Authorization Primary

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.