CVE-2026-59254: n8n: External Secrets Accessible via Workflow Expressions Outside Credentials

External secrets let n8n pull values from a secrets store such as a vault. They are meant to be used in credentials only. Because of this flaw they also resolved in ordinary node expressions (CWE-639, authorization bypass). A project editor writes an expression that references an external secret, runs or previews it, and sees the plaintext value. The editor needs no explicit secrets access permission.

The attacker needs an authenticated account with editor access to a project. No user interaction is needed. The instance must have the external secrets feature configured, otherwise there is nothing to read.

The CVSS 4.0 vector shows no confidentiality impact on n8n itself but high impact on subsequent systems. That fits: the leaked values are keys and passwords for other services, such as cloud accounts and databases. Anyone who can edit a project can in effect read every external secret the instance knows, so the permission model that separates editors from secret holders does not hold.

Affected: n8n below 2.27.4, and 2.28.0. The fixed releases are 2.27.4 on that line and 2.28.1. Only instances with the external secrets feature configured are exposed, and the risk is highest where editors are less trusted than secret administrators.

Check the version:

npm ls n8n

For Docker, check the image tag or the version in the UI.

Upgrade to n8n 2.27.4 or 2.28.1, or later. For an npm install, run npm install [email protected].

Temporary mitigations from the advisory, neither of which fully removes the risk:

• Restrict project membership to fully trusted users.
• Do not grant editor access to projects on instances where external secrets are configured.

If untrusted editors had access on an unpatched version, rotate the external secrets they could have read.

Search workflows for node expressions that reference external secrets, where credentials should be the only consumer. Look at who last edited those workflows and whether they hold secrets permissions. Check the secrets provider's access logs for reads from the n8n instance that do not match credential use. Review whether any listed secret was later used from an unexpected address.

Impact

External secrets were incorrectly resolved in workflow node expressions, where they are not intended to be available. An authenticated user with project editor access could read the plaintext value of external secrets by referencing them in a node expression, without needing explicit secrets access permissions.

This issue only affects instances with the external secrets feature configured.

Patches

The issue has been fixed in n8n versions 2.27.4 and 2.28.1. 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 project membership to fully trusted users only.
• Avoid granting editor access to projects on instances where external secrets are configured.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.