CVE-2026-42227: n8n Public API Variables IDOR Allows Cross-Project Secret Disclosure

Advisory

• Link: https://github.com/n8n-io/n8n/security/advisories/GHSA-756q-gq9h-fp22
• Affected versions: < 1.123.32, < 2.17.4, < 2.18.1
• Patched versions: 1.123.32, 2.17.4, 2.18.1

Description

An IDOR in the public variables API allows authenticated users to read project variables outside their authorized project scope.

The vulnerable handler (variables.handler.ts) directly queries VariablesRepository with a user-controlled projectId, instead of enforcing membership checks through VariablesService.

In enterprise/team setups with multiple projects, a regular member with variable:list scope can read variables from projects they do not belong to, including sensitive values.

This issue only affects licensed enterprise or team deployments with multiple projects and the variables feature enabled.

Source - Sink Analysis

The vulnerable code path is the public API list endpoint in packages/cli/src/public-api/v1/handlers/variables/variables.handler.ts:

const [variables, count] = await Container.get(VariablesRepository).findAndCount({
  skip: offset,
  take: limit,
  where: {
    project: projectId === 'null' ? IsNull() : { id: projectId },
    value: state === 'empty' ? '' : undefined,
  },
  relations: ['project'],
});

This path does not validate whether req.user has access to the requested project.

The internal enterprise controller uses the authorization-aware service path instead (variables.controller.ee.ts → variables.service.ee.ts), which filters by project membership (projectVariable:list scope).

The feature is license-gated via isLicensed('feat:variables'), so exploitability is limited to licensed editions.

The response model includes variable value (variable.yml), making this a confidentiality issue.

Proof of Concept

1. Set up an enterprise/team n8n instance with at least two projects:

   • Project A (attacker is a member)
   • Project B (attacker is not a member)
   • Add one or more variables to Project B

2. Create an API key for the attacker account with variable:list scope.

3. Query variables for the unauthorized project:

curl -X GET 'http://target:5678/api/v1/variables?projectId=PROJECT_B_ID' \
  -H 'X-N8N-API-KEY: ATTACKER_MEMBER_API_KEY'

4. Observe that variables from Project B are returned even though the attacker is not a member.

5. Optional: iterate project IDs to enumerate and exfiltrate variables across projects.

Impact

This is a cross-project authorization bypass in the public API that leaks secrets across project boundaries.

Any authenticated low-privilege member with variable:list scope can read unauthorized project variables, including API keys, tokens, internal endpoints, and environment secrets stored in variables.

Exploitability conditions:

• Multi-project enterprise/team deployment
• At least one project the attacker is not a member of
• Valid API key with variable:list scope

If variables were misused to store sensitive information such as credentials or tokens, they should be rotated immediately.

n8n (verified in: 2.7.4 and 2.9.2) CWE-639: Authorization Bypass Through User-Controlled Key (IDOR)