CVE-2026-42227 Overview
CVE-2026-42227 is an authorization bypass vulnerability in n8n, an open source workflow automation platform. The flaw exists in the public API variables endpoint, where the handler queries the variables repository directly without enforcing project membership checks. An authenticated user holding an API key scoped to variable:list can read variables from projects they do not belong to by supplying an arbitrary projectId query parameter. The vulnerability affects licensed enterprise and team deployments running multiple projects with the variables feature enabled. Patched releases are available in versions 1.123.32, 2.17.4, and 2.18.1.
Critical Impact
Authenticated attackers with low-privilege API keys can exfiltrate variables from projects they are not members of, potentially exposing credentials, tokens, or other sensitive data stored in n8n variables.
Affected Products
- n8n Enterprise versions prior to 1.123.32
- n8n versions prior to 2.17.4 (2.17.x branch)
- n8n version 2.18.0 (fixed in 2.18.1)
Discovery Timeline
- 2026-05-04 - CVE-2026-42227 published to NVD
- 2026-05-06 - Last updated in NVD database
Technical Details for CVE-2026-42227
Vulnerability Analysis
The vulnerability is an Authorization Bypass Through User-Controlled Key issue, classified under [CWE-639]. n8n exposes a public API endpoint that returns variables associated with a project. Each authenticated request includes an API key with a defined permission scope. When a request reaches the variables endpoint with a projectId query parameter, the handler trusts that parameter and queries the variables repository directly.
The handler bypasses the authorization-aware service layer used by the internal enterprise controller. That service layer normally validates that the requesting user is a member of the target project before returning results. By skipping it, the public API path performs no project membership check. Any user with a valid API key carrying the variable:list scope can enumerate variables across every project in the deployment.
If operators stored credentials, API tokens, or other secrets in n8n variables, those values are exposed and must be rotated. The vulnerability does not permit modification or deletion of variables, limiting impact to confidentiality.
Root Cause
The public API variables handler invokes the repository layer directly instead of routing through the authorization-aware service used by the enterprise controller. Project membership enforcement was implemented at the service layer only, not at the data access layer.
Attack Vector
An attacker authenticates to the n8n public API with any valid API key holding the variable:list scope. The attacker then issues a GET request to the variables endpoint and supplies a projectId query parameter referencing a project they are not a member of. The server returns the requested project's variables without verifying membership. Discovery of project identifiers can be performed through enumeration or through other low-privilege API responses.
The vulnerability mechanism is described in the GitHub Security Advisory GHSA-756q-gq9h-fp22.
Detection Methods for CVE-2026-42227
Indicators of Compromise
- Public API requests to the variables endpoint that include a projectId query parameter referencing projects the requesting API key owner is not a member of.
- Spikes in variable:list API calls from a single API key across multiple distinct projectId values.
- Access logs showing successful 200 responses on variables queries originating from non-administrative API keys.
Detection Strategies
- Correlate API key identity with project membership records and alert when the two diverge for variables endpoint requests.
- Review n8n audit logs for sequential or scripted enumeration of projectId parameters on the public API.
- Compare service-layer vs repository-layer access patterns to surface paths that bypass authorization checks.
Monitoring Recommendations
- Forward n8n application and reverse-proxy logs to a centralized SIEM and create rules for cross-project variable access.
- Monitor outbound traffic from systems that previously had secrets stored in n8n variables for signs of credential reuse.
- Track API key creation, scope assignment, and usage frequency to identify keys with anomalous variable enumeration patterns.
How to Mitigate CVE-2026-42227
Immediate Actions Required
- Upgrade n8n to version 1.123.32, 2.17.4, or 2.18.1 depending on the deployed branch.
- Rotate any credentials, tokens, or secrets that were stored in n8n variables, since exposure cannot be ruled out without log review.
- Audit existing API keys and revoke any that hold the variable:list scope unnecessarily.
Patch Information
n8n released fixes in versions 1.123.32, 2.17.4, and 2.18.1. The patches route the public API variables handler through the authorization-aware service layer that enforces project membership. Refer to the n8n GitHub Security Advisory for release details.
Workarounds
- Disable the variables feature on enterprise or team deployments until upgrades are applied.
- Restrict the variable:list scope to API keys owned by trusted administrators only.
- Place the n8n public API behind a reverse proxy that filters or denies requests carrying a projectId query parameter on the variables endpoint.
# Upgrade n8n via npm to a patched release
npm install -g n8n@2.18.1
# Or pull a patched container image
docker pull n8nio/n8n:2.18.1
docker pull n8nio/n8n:2.17.4
docker pull n8nio/n8n:1.123.32
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
