Mar 26, 2026·5 min read·3 visits
Authenticated n8n users lacking necessary permissions can extract plaintext secrets from external vaults (e.g., AWS, HashiCorp) by referencing guessed secret names during credential creation. Upgrading to versions 1.123.23 or 2.6.4 mitigates this vulnerability.
An incorrect authorization vulnerability in the n8n workflow automation platform permits authenticated, low-privileged users to extract plaintext secrets from connected external vaults. By bypassing specific permission checks during credential creation, attackers can compromise sensitive infrastructure credentials.
The n8n workflow automation platform supports integration with external secret vaults, such as AWS Secrets Manager and HashiCorp Vault. This integration allows administrators to manage sensitive data centrally while referencing these secrets within n8n workflows and credentials. The platform implements an authorization model to restrict access to these external secrets, specifically relying on the externalSecret:list permission to govern visibility and retrieval operations.
CVE-2026-33722 represents a critical authorization bypass flaw classified under CWE-863 (Incorrect Authorization). The vulnerability exists within the application logic responsible for processing and saving new credentials. While dedicated endpoints for listing external secrets enforce the necessary permission checks, the credential creation routine fails to independently verify the user's authorization level when external secrets are referenced by name.
Consequently, an authenticated user with baseline platform access can exploit this disjointed authorization model. The vulnerability enables attackers to extract the plaintext values of stored secrets, bypassing the intended access controls entirely. This exposes the underlying infrastructure to severe lateral movement risks if administrative or operational credentials are compromised.
The fundamental flaw resides in the separation of secret resolution logic from the primary authorization enforcement point. When a user queries the external secrets API directly, the n8n backend correctly validates the externalSecret:list permission. If the user lacks this permission, the application rejects the request and denies access to the vault inventory.
However, the backend utilizes a shared utility function to resolve secret references when a user submits a payload to the /credentials endpoint. This resolution function processes the credential payload, identifies any external secret identifiers, and automatically fetches the corresponding plaintext values from the configured vault. The vulnerability occurs because this execution path invokes the resolution function without validating the context of the calling user.
Because the credential saving routine assumes the user is authorized to construct the credential, the backend silently completes the external secret retrieval. The resulting plaintext value is either returned in the API response or stored in a localized format accessible to the low-privileged user. This implementation creates a direct blind spot where authorization is assumed rather than explicitly verified.
Exploitation of CVE-2026-33722 requires three preconditions: the target n8n instance must have an external vault configured, the attacker must possess a valid user account, and the attacker must know or guess the exact identifier of the target secret. Since the attacker cannot list the secrets due to the functional externalSecret:list check, the attack relies on targeted reconnaissance or dictionary-based guessing of common secret names (e.g., PROD_DB_PASSWORD, AWS_ACCESS_KEY).
The attack begins with the adversary crafting a malicious HTTP POST request directed at the /credentials endpoint. The payload is structured as a standard credential creation request but contains a specific reference mapping to the targeted external secret name.
{
"name": "Exploit_Credential",
"type": "aws",
"nodesAccess": [],
"data": {
"accessKeyId": {
"$ref": "=/externalSecrets/AWS_ACCESS_KEY"
}
}
}Upon processing this payload, the n8n backend parses the $ref directive. The system contacts the external vault, requests the value for AWS_ACCESS_KEY, and embeds the returned plaintext into the application's response or stores it in the local database under the attacker's ownership. The attacker then reads the extracted plaintext directly from the application interface or API response, achieving total compromise of the targeted secret.
The successful exploitation of this vulnerability yields a high confidentiality impact, allowing unauthorized extraction of sensitive operational data. Because n8n is fundamentally designed to integrate disparate systems, the credentials stored within external vaults often possess broad administrative privileges over cloud environments, databases, and third-party SaaS applications.
The CVSS 4.0 vector (CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:H) accurately reflects the severity of this flaw. The attack requires low privileges (PR:L) and network access (AV:N), with no user interaction (UI:N). The vulnerability demonstrates a high subsequent impact (SC:H, SI:H, SA:H) because the stolen credentials immediately facilitate secondary attacks against the connected infrastructure.
While the integrity and availability of the n8n application itself remain unaffected (VI:N, VA:N), the external systems managed by the exposed credentials face immediate risk of compromise. Organizations utilizing n8n for CI/CD pipelines, automated infrastructure provisioning, or database management are exposed to critical supply chain and data exfiltration risks.
The vendor has addressed this vulnerability in n8n versions 1.123.23 (for the 1.x release branch) and 2.6.4 (for the 2.x release branch). The patch introduces strict context-aware permission checks within the credential resolution logic. Organizations must upgrade their n8n deployments to these secure versions immediately to eliminate the exposure.
If an immediate upgrade is structurally unfeasible, administrators must implement temporary mitigations. The primary workaround involves disabling the external secrets integration within the n8n configuration. Alternatively, administrators should review user roles and restrict platform access exclusively to highly trusted personnel, effectively removing the internal threat vector.
Security teams should proactively audit n8n application logs for indicators of compromise. Analysts must scrutinize the /credentials endpoint for high volumes of creation or modification requests originating from low-privileged accounts. Furthermore, any external secrets that are suspected to have been exposed must be rotated immediately within the origin vault to invalidate the stolen material.
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:H| Product | Affected Versions | Fixed Version |
|---|---|---|
n8n n8n-io | < 1.123.23 | 1.123.23 |
n8n n8n-io | >= 2.0.0-rc.0, < 2.6.4 | 2.6.4 |
| Attribute | Detail |
|---|---|
| CWE ID | CWE-863 |
| Attack Vector | Network |
| CVSS Score | 7.3 |
| Exploit Status | none |
| KEV Status | Not Listed |
| Impact | High Confidentiality |
The software performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.