CVE-2026-59259: n8n permission bypass exposes

Q: Is CVE-2026-59259 actively exploited?

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

Q: How to fix CVE-2026-59259?

Upgrade immediately to n8n 1.123.61, 2.27.4, or 2.28.1, whichever matches your release line. If immediate patching isn't possible, audit and tighten Advanced Permissions role assignments so that credential create/update rights are restricted to the same trust tier as externalSecret:list, or temporarily disable the external secrets provider integration. Review credential edit history and workflow execution logs for expression syntax referencing external secret paths from users who shouldn't have that visibility, and rotate any secrets that may have been exposed through affected credentials as a precaution given the lack of CVSS/EPSS data to otherwise bound the blast radius.

Q: What systems are affected by CVE-2026-59259?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow orchestration platforms, secrets management integrations.

Q: What is the CVSS score for CVE-2026-59259?

No CVSS score has been assigned yet.

CISO Take

n8n has a permission bypass in its external secrets handling: a user who can create or update credentials, but who lacks the externalSecret:list scope, can embed a reference to an external secret inside a credential in a form the static permission check doesn't catch, and that reference silently resolves to the real secret value when the workflow runs. This matters because it defeats the exact RBAC boundary Advanced Permissions is supposed to enforce between workflow builders and secrets administrators, meaning a lower-trust automation author can pull cloud keys, database credentials, or LLM API keys they were explicitly denied visibility into. There's no CVSS score, no EPSS data, no CISA KEV listing, and no public exploit or Nuclei template yet, so this looks like a disclosed design flaw rather than something under active exploitation — but n8n has 16 downstream dependents and 136 other CVEs in its history, so the platform is a recurring target. Only instances with an external secrets provider configured AND Advanced Permissions enabled are exposed, which narrows the blast radius to enterprise-tier deployments. Patch to 1.123.61, 2.27.4, or 2.28.1 now, and in the meantime audit who holds credential create/update rights versus externalSecret:list, since that gap is exactly what this bug abuses.

Sources: NVD GitHub Advisory CISA KEV OpenSSF ATLAS

What is the risk?

Moderate-to-high risk despite the absence of a CVSS score or EPSS data: exploitation requires an already-authenticated internal user with a specific, narrow permission combination (credential create/update without externalSecret:list), which limits this to insider-threat or compromised-low-privilege-account scenarios rather than opportunistic internet-wide attacks. There is no public PoC, no Nuclei template, and it is not in CISA KEV, so near-term mass exploitation is unlikely. However, the impact is severe where it applies: it collapses a deliberate authorization boundary (Advanced Permissions + external secrets provider) that enterprises specifically configure to segregate who can see high-value secrets, so any organization relying on that separation for compliance or least-privilege reasons should treat this as materially reducing their control assurance until patched.

How does the attack unfold?

Initial Access

An authenticated internal user holds credential create/update permission but lacks the externalSecret:list scope needed to view external secrets directly.

AML.T0012

Bypass Static Validation

The user embeds an external secret reference inside a credential field in a form the static permission check does not detect, exploiting the mismatch with the runtime expression engine.

Runtime Resolution

When the workflow executes, n8n's expression engine resolves the embedded reference and returns the actual secret value into the node's execution output.

AML.T0055

Impact

The user reads the execution log/output and obtains a secret value (e.g., cloud or database credential) they were explicitly not authorized to access, enabling lateral privilege escalation.

AML.T0083

Initial Access

An authenticated internal user holds credential create/update permission but lacks the externalSecret:list scope needed to view external secrets directly.

AML.T0012

Bypass Static Validation

The user embeds an external secret reference inside a credential field in a form the static permission check does not detect, exploiting the mismatch with the runtime expression engine.

Runtime Resolution

When the workflow executes, n8n's expression engine resolves the embedded reference and returns the actual secret value into the node's execution output.

AML.T0055

Impact

The user reads the execution log/output and obtains a secret value (e.g., cloud or database credential) they were explicitly not authorized to access, enabling lateral privilege escalation.

AML.T0083

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
n8n	npm	< 1.123.61	`1.123.61`
206.1K OpenSSF 6.7 Pushed 5d ago 53% patched ~5d to patch Full package profile →

Do you use n8n? You're affected.

How severe is it?

CVSS 3.1

N/A

EPSS

0.4%

chance of exploitation in 30 days

Higher than 36% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What should I do?

1 step

Upgrade immediately to n8n 1.123.61, 2.27.4, or 2.28.1, whichever matches your release line. If immediate patching isn't possible, audit and tighten Advanced Permissions role assignments so that credential create/update rights are restricted to the same trust tier as externalSecret:list, or temporarily disable the external secrets provider integration. Review credential edit history and workflow execution logs for expression syntax referencing external secret paths from users who shouldn't have that visibility, and rotate any secrets that may have been exposed through affected credentials as a precaution given the lack of CVSS/EPSS data to otherwise bound the blast radius.

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 Data Leakage Agent Framework AML.T0012 - Valid Accounts AML.T0055 - Unsecured Credentials AML.T0083 - Credentials from AI Agent Configuration

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.4 - AI system operational security controls

OWASP LLM Top 10

LLM06 - Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2026-59259?

n8n has a permission bypass in its external secrets handling: a user who can create or update credentials, but who lacks the externalSecret:list scope, can embed a reference to an external secret inside a credential in a form the static permission check doesn't catch, and that reference silently resolves to the real secret value when the workflow runs. This matters because it defeats the exact RBAC boundary Advanced Permissions is supposed to enforce between workflow builders and secrets administrators, meaning a lower-trust automation author can pull cloud keys, database credentials, or LLM API keys they were explicitly denied visibility into. There's no CVSS score, no EPSS data, no CISA KEV listing, and no public exploit or Nuclei template yet, so this looks like a disclosed design flaw rather than something under active exploitation — but n8n has 16 downstream dependents and 136 other CVEs in its history, so the platform is a recurring target. Only instances with an external secrets provider configured AND Advanced Permissions enabled are exposed, which narrows the blast radius to enterprise-tier deployments. Patch to 1.123.61, 2.27.4, or 2.28.1 now, and in the meantime audit who holds credential create/update rights versus externalSecret:list, since that gap is exactly what this bug abuses.

Is CVE-2026-59259 actively exploited?

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

How to fix CVE-2026-59259?

Upgrade immediately to n8n 1.123.61, 2.27.4, or 2.28.1, whichever matches your release line. If immediate patching isn't possible, audit and tighten Advanced Permissions role assignments so that credential create/update rights are restricted to the same trust tier as externalSecret:list, or temporarily disable the external secrets provider integration. Review credential edit history and workflow execution logs for expression syntax referencing external secret paths from users who shouldn't have that visibility, and rotate any secrets that may have been exposed through affected credentials as a precaution given the lack of CVSS/EPSS data to otherwise bound the blast radius.

What systems are affected by CVE-2026-59259?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow orchestration platforms, secrets management integrations.

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

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksworkflow orchestration platformssecrets management integrations

MITRE ATLAS Techniques

AML.T0012 Valid Accounts

AML.T0055 Unsecured Credentials

AML.T0083 Credentials from AI Agent Configuration

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2.4

OWASP LLM Top 10: LLM06

What are the technical details?

Original Advisory

n8n before versions 1.123.61, 2.27.4, and 2.28.1 contains a permission bypass vulnerability in external secrets handling caused by a mismatch between the static validation check and the runtime expression engine. An authenticated user with credential create or update permissions but without the externalSecret:list scope can embed external secret references into credentials in forms the static validation does not detect; these references resolve at workflow execution time, exposing secret values the user is not authorized to access. This issue only affects instances where an external secrets provider is configured and Advanced Permissions are in use.

Exploitation Scenario

An internal n8n user with credential create/update permission but without externalSecret:list access edits a credential and embeds an expression-based reference to an external secret path they were never granted visibility into, structuring it in a way that slips past the static permission validator (the mismatch between the validator and the actual expression engine). They then run the workflow; at execution time n8n's expression engine resolves the reference and injects the real secret value into the node's output. The user views the execution result or log and now holds a credential — e.g., a cloud API key or database password — that Advanced Permissions was explicitly configured to keep from them.

Weaknesses (CWE)

CWE-639 Authorization Bypass Through User-Controlled Key Primary CWE-639 Authorization Bypass Through User-Controlled Key Primary CWE-639 Authorization Bypass Through User-Controlled Key

CWE-639 — Authorization Bypass Through User-Controlled Key: The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.

[Architecture and Design] For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.
[Architecture and Design, Implementation] Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.

Source: MITRE CWE corpus.