CVE-2026-42227: 
NixOS vulnerability analysis and mitigation

CVE-2026-42227 is an Insecure Direct Object Reference (IDOR) / authorization bypass vulnerability in n8n, an open-source workflow automation platform, that allows authenticated users to read project variables across projects they are not authorized to access. Discovered and published on April 22, 2026 by researchers nkoorty and jjjutla, it was publicly disclosed via GitHub Advisory GHSA-756q-gq9h-fp22 on April 29, 2026. Affected versions include all n8n enterprise/team releases before 1.123.32, versions 2.0.0–2.17.3, and version 2.18.0. It carries a CVSS v3.1 score of 6.5 (Medium) and a CVSS v4.0 score of 6.0 (Medium) (GitHub Advisory, n8n Security Advisory).

The root cause is CWE-639 (Authorization Bypass Through User-Controlled Key): the public API variables endpoint accepted an arbitrary projectId query parameter and passed it directly to the variables repository layer without verifying that the requesting user was a member of the specified project. This bypassed the authorization-aware service layer used by the internal enterprise controller, which does enforce project membership checks. An attacker only needs a valid API key scoped to variable:list — a low-privilege permission — to enumerate variables from any project by iterating over projectId values. No public proof-of-concept code has been identified, but the attack mechanics are straightforward given the advisory description (n8n Security Advisory, GitHub Advisory).

Successful exploitation allows an authenticated but low-privileged user to read all variables from any project within the same n8n enterprise or team deployment, regardless of project membership. If variables were used to store sensitive data such as API credentials, tokens, passwords, or other secrets, those values are fully exposed to the attacker. The vulnerability has no integrity or availability impact, but the confidentiality breach could enable lateral movement or further compromise of integrated third-party services if stolen credentials are reused. This issue is limited to licensed enterprise or team deployments with multiple projects and the variables feature enabled (n8n Security Advisory).

No public exploit code or in-the-wild exploitation has been reported as of the time of this report. The EPSS score is approximately 0.038% (12th percentile), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires a valid API key with variable:list scope, limiting the attacker pool to authenticated users of the platform (GitHub Advisory).

1. Obtain API Key: Acquire a valid n8n API key scoped to variable:list — this may be obtained via a low-privilege account, a free trial, or social engineering.
2. Identify Target Instance: Confirm the target is a licensed n8n enterprise or team deployment with multiple projects and the variables feature enabled (versions prior to 1.123.32, 2.17.4, or 2.18.1).
3. Enumerate Project IDs: Query the n8n public API to discover valid projectId values. Project IDs may be discoverable through other API endpoints accessible to the attacker's account.
4. Exploit the IDOR: Send a GET request to the public API variables endpoint with an arbitrary projectId query parameter corresponding to a project the attacker is not a member of, e.g.:

   GET /api/v1/variables?projectId=<target-project-id>
   Authorization: Bearer <api-key>

5. Harvest Secrets: Parse the API response to extract variable names and values, which may include credentials, tokens, or other sensitive configuration data stored by other project teams.
6. Leverage Stolen Credentials: Use any harvested credentials to access integrated third-party services or escalate access within the organization (n8n Security Advisory, GitHub Advisory).

• Network: Unusual API requests to the n8n variables endpoint (/api/v1/variables) with projectId query parameters referencing projects the authenticated user is not a member of; repeated requests cycling through multiple projectId values from a single API key.
• Logs: n8n API access logs showing GET /api/v1/variables?projectId=<id> requests from a user account across many different project IDs in a short time window; API key usage outside of normal business hours or from unexpected IP addresses.
• Behavioral: A single API key with variable:list scope making an unusually high volume of variable listing requests across multiple projects; API key activity from accounts that are not members of the projects being queried.

Upgrade n8n to one of the patched versions: 1.123.32, 2.17.4, or 2.18.1 (or later). If immediate upgrade is not possible, restrict n8n access and API key issuance to fully trusted users only, and audit all project variables for sensitive values — any credentials or tokens stored as variables should be rotated immediately. These workarounds do not fully remediate the risk and should only be used as short-term measures until patching is complete (n8n Security Advisory).

The vulnerability was reported by security researchers nkoorty and jjjutla and disclosed responsibly through GitHub's security advisory process. A technical write-up was published at infinitsec.net shortly after disclosure, describing the issue as an IDOR enabling cross-project secret disclosure. No major vendor statements beyond the official n8n advisory or significant social media controversy have been identified (n8n Security Advisory).