CVE-2026-54307: n8n: credential hijack via partial authorization bypass

GHSA-pmqw-72cg-wx85 CRITICAL
Published June 16, 2026
CISO Take

n8n's workflow sharing feature contains a critical authorization flaw (CVSS 9.6) that allows any member-level user with editor access to a shared workflow to reference and access credentials owned by other users — including admins — through public API endpoints where ownership checks are only partially enforced. For organizations running AI agent pipelines in n8n, the blast radius is severe: n8n credentials routinely include API keys for LLM providers (OpenAI, Anthropic), cloud storage, and databases, meaning a single low-privilege account can harvest the keys powering the entire AI stack. With an EPSS in the top 87th percentile and no public exploit yet available, the exploitation window is open and closing fast. Patch immediately to n8n 1.123.55, 2.25.7, or 2.26.2; if upgrading is blocked, restrict workflow sharing to admins only, audit all shared workflows for unexpected credential references, and rotate all credentials stored in the instance.

Sources: NVD EPSS GitHub Advisory OpenSSF ATLAS

What is the risk?

Critical risk. CVSS 9.6 with Scope:Changed indicates the vulnerability crosses security boundaries — a member-level user can pivot to credentials owned by privileged accounts. The attack requires only low privileges (any authenticated member with editor access to one shared workflow) and zero user interaction, making it scriptable and scalable. n8n's 105-CVE history and OpenSSF score of 6.5/10 indicate a sustained pattern of security debt in this package. Although no public exploit exists and CISA KEV listing is absent, the EPSS top-87th-percentile signal reflects active threat-actor interest. The blast radius scales linearly with the number of credentials stored in the instance — in AI-heavy deployments this can represent dozens of high-value API keys.

How does the attack unfold?

Initial Access
Attacker authenticates to n8n with a legitimate member-level account obtained via insider access, credential stuffing, or phishing of a low-privilege team member.
AML.T0012
Authorization Bypass
Attacker, holding editor access to at least one shared workflow, crafts API requests referencing credential IDs owned by other users, exploiting partial ownership check enforcement in public endpoints.
AML.T0049
Credential Harvesting
Vulnerable API returns credential data belonging to other users — including admin-owned LLM API keys, cloud IAM tokens, and database passwords — which the attacker collects and exfiltrates.
AML.T0083
Lateral Movement & Impact
Harvested API keys grant unauthorized access to connected AI services and cloud infrastructure, enabling data exfiltration from vector stores or S3, cost harvesting from LLM providers, or injection of malicious configurations into AI agent pipelines.
AML.T0085

What systems are affected?

Package Ecosystem Vulnerable Range Patched
n8n npm < 1.123.55 1.123.55
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
9.6 / 10
EPSS
0.0%
chance of exploitation in 30 days
Higher than 13% of all CVEs
Exploitation Status
No known exploitation
Sophistication
Trivial

What is the attack surface?

AV AC PR UI S C I A
AV Network
AC Low
PR Low
UI None
S Changed
C High
I High
A None

What should I do?

5 steps
  1. Patch immediately: upgrade to n8n 1.123.55 (v1 branch), 2.25.7, or 2.26.2 — these are the only versions with the credential ownership enforcement fix.

  2. If patching is blocked: disable workflow sharing entirely or restrict it to admin-tier accounts and fully trusted users only via the n8n access control settings.

  3. Audit: enumerate all shared workflows and inspect their credential references; any credential referenced by a node owned by a different user should be treated as potentially compromised.

  4. Rotate: proactively rotate all credentials stored in n8n — especially LLM API keys, cloud IAM keys, and database passwords — even in the absence of confirmed exploitation.

  5. Detect: monitor n8n audit logs and API gateway logs for GET requests to credential endpoints (e.g., /api/v1/credentials/*) originating from member-level accounts, particularly outside business hours or from unexpected IPs.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Art. 15 - Accuracy, robustness and cybersecurity Art. 9 - Risk management system
ISO 42001
A.6.2 - AI system roles and responsibilities A.8.4 - Protection of AI system records and credentials
NIST AI RMF
GOVERN 6.1 - Policies and procedures for AI security risk management
OWASP LLM Top 10
LLM06:2025 - Excessive Agency

Frequently Asked Questions

What is CVE-2026-54307?

n8n's workflow sharing feature contains a critical authorization flaw (CVSS 9.6) that allows any member-level user with editor access to a shared workflow to reference and access credentials owned by other users — including admins — through public API endpoints where ownership checks are only partially enforced. For organizations running AI agent pipelines in n8n, the blast radius is severe: n8n credentials routinely include API keys for LLM providers (OpenAI, Anthropic), cloud storage, and databases, meaning a single low-privilege account can harvest the keys powering the entire AI stack. With an EPSS in the top 87th percentile and no public exploit yet available, the exploitation window is open and closing fast. Patch immediately to n8n 1.123.55, 2.25.7, or 2.26.2; if upgrading is blocked, restrict workflow sharing to admins only, audit all shared workflows for unexpected credential references, and rotate all credentials stored in the instance.

Is CVE-2026-54307 actively exploited?

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

How to fix CVE-2026-54307?

1. Patch immediately: upgrade to n8n 1.123.55 (v1 branch), 2.25.7, or 2.26.2 — these are the only versions with the credential ownership enforcement fix. 2. If patching is blocked: disable workflow sharing entirely or restrict it to admin-tier accounts and fully trusted users only via the n8n access control settings. 3. Audit: enumerate all shared workflows and inspect their credential references; any credential referenced by a node owned by a different user should be treated as potentially compromised. 4. Rotate: proactively rotate all credentials stored in n8n — especially LLM API keys, cloud IAM keys, and database passwords — even in the absence of confirmed exploitation. 5. Detect: monitor n8n audit logs and API gateway logs for GET requests to credential endpoints (e.g., /api/v1/credentials/*) originating from member-level accounts, particularly outside business hours or from unexpected IPs.

What systems are affected by CVE-2026-54307?

This vulnerability affects the following AI/ML architecture patterns: AI agent orchestration platforms, LLM integration pipelines, Multi-tenant workflow automation, Cloud-connected AI deployments, AI agent frameworks with external credential stores.

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

CVE-2026-54307 has a CVSS v3.1 base score of 9.6 (CRITICAL). The EPSS exploitation probability is 0.04%.

What is the AI security impact?

Affected AI Architectures

AI agent orchestration platformsLLM integration pipelinesMulti-tenant workflow automationCloud-connected AI deploymentsAI agent frameworks with external credential stores

MITRE ATLAS Techniques

AML.T0012 Valid Accounts
AML.T0049 Exploit Public-Facing Application
AML.T0055 Unsecured Credentials
AML.T0083 Credentials from AI Agent Configuration
AML.T0106 Exploitation for Credential Access

Compliance Controls Affected

EU AI Act: Art. 15, Art. 9
ISO 42001: A.6.2, A.8.4
NIST AI RMF: GOVERN 6.1
OWASP LLM Top 10: LLM06:2025

What are the technical details?

Original Advisory

## Impact A member-level user with editor access to a shared workflow could reference credentials they do not own via specific public API endpoints. Credential ownership checks were only enforced partially leading to cross-user credential access. This issue affects instances where workflow sharing is enabled and at least one workflow has been shared with a member-level user as an Editor. ## 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 sharing to fully trusted users only. - Audit shared workflows for unexpected credential references or recent modifications. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures. **Credits:** Momen Elkhouli

Exploitation Scenario

An attacker with insider access or a compromised member account in an organization's n8n instance identifies shared workflows they hold editor access to. Using publicly documented n8n API endpoint patterns, the attacker crafts requests that reference credential IDs belonging to other users — admin-owned credentials for OpenAI, AWS, and a production vector database. Because ownership enforcement on these endpoints is partial, the API returns the credential data. Within minutes the attacker possesses API keys for the organization's entire AI stack. They use the OpenAI key for unauthorized inference and data extraction, the AWS key to access S3 buckets containing fine-tuning datasets, and inject a malicious system prompt configuration into a shared n8n AI agent workflow that will persist for subsequent legitimate executions.

Weaknesses (CWE)

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.

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N

Timeline

Published
June 16, 2026
Last Modified
June 16, 2026
First Seen
June 17, 2026

Related Vulnerabilities