CVE-2026-103252 in n8n
Summary
by MITRE • 10/01/2026
n8n versions before 1.123.80, from 2.0.0 before 2.39.6, and from 2.40.0 before 2.40.1 contain an authorization bypass vulnerability in the credential test endpoint that resolves project-scoped variables without validating caller access. Attackers can specify an arbitrary project ID in the request body to interpolate sensitive variables into credential test requests sent to attacker-controlled hosts for exfiltration.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/02/2026
The n8n automation platform, a popular tool for workflow orchestration and integration, contains a critical authorization bypass vulnerability affecting multiple version ranges including versions prior to 1.123.80 in the legacy branch, as well as versions from 2.0.0 up to but not including 2.39.6, and versions from 2.40.0 up to but not including 2.40.1. This vulnerability resides specifically within the credential testing endpoint, a functionality designed to allow users to verify that their stored credentials are valid by attempting a connection with external services. The core technical flaw is an improper access control mechanism where the system fails to validate whether the authenticated user has permission to access or interact with the specific project ID provided in the request payload. Instead of restricting variable resolution and credential usage to only those resources explicitly authorized for the current session, the application resolves project-scoped variables based solely on the identifier present in the incoming HTTP request body. This architectural oversight allows an attacker who possesses valid authentication credentials for any user account within the n8n instance to manipulate the context of the operation by injecting a maliciously crafted project ID that belongs to another tenant or administrative scope, thereby bypassing logical access controls intended to isolate data between different projects or organizations.
The operational impact of this vulnerability is severe due to its potential for sensitive information exfiltration through server-side request forgery patterns. When an attacker submits a credential test request containing an arbitrary project ID that they do not own but have knowledge of, the backend processes the request by resolving variables scoped to that unauthorized project. These resolved values often include high-privilege secrets such as API keys, database connection strings, OAuth tokens, or other authentication credentials stored within n8n for integration purposes. The credential testing mechanism then attempts to use these interpolated sensitive variables to establish a connection with an external host. If the attacker controls this destination host, they can capture the full HTTP request sent by n8n during the test phase. This effectively turns the vulnerability into a vector for data theft, as the intercepted requests will contain the actual secret values in plaintext or encoded formats depending on the specific integration protocol used. Consequently, an authenticated low-privilege user could potentially escalate their impact to that of a high-privilege attacker by stealing credentials from other projects within the same instance, leading to unauthorized access to downstream systems and potential compromise of broader organizational infrastructure connected via these integrations.
From a classification perspective, this vulnerability aligns with CWE-284 Improper Access Control, specifically reflecting failures in authorization logic where user input is not sufficiently validated against resource ownership policies before processing sensitive operations. It also relates closely to CWE-913 Improvement of Dynamic Variable References for Uncontrolled Modification of Scope, as the application dynamically resolves variables based on an attacker-controlled identifier without verifying scope boundaries. In terms of adversary tactics, this exploit maps directly to ATT&CK technique T1504 Weak or Compromised Authentication Credentials and potentially T1078 Valid Accounts if the initial access is gained through compromised credentials. Furthermore, the mechanism of sending requests to external hosts with sensitive data in headers or bodies corresponds to aspects of T1041 Exfiltration Over C2 Channel when considering how n8n acts as a proxy for leaking secrets out of the network perimeter via its outbound connections during credential validation.
Mitigation strategies must prioritize immediate software updates and rigorous input validation practices. The primary remediation is to upgrade all affected instances of n8n to version 1.123.80 or later, or versions 2.39.6 and 2.40.1 and above, where the authorization checks for project-scoped variables have been corrected to ensure that only users with explicit access rights can trigger credential tests against resources within their authorized projects. For organizations unable to patch immediately due to operational constraints, implementing a Web Application Firewall rule set to detect and block requests to the credential test endpoint containing suspiciously formatted or unauthorized project IDs may provide temporary relief, though this is not a substitute for code-level fixes. Additionally, security teams should audit existing workflows to ensure that no critical secrets are stored in n8n without additional encryption at rest if possible, and monitor outbound network traffic from n8n servers for unusual connection attempts to unknown external hosts, which could indicate active exploitation of this vulnerability. Regular penetration testing focusing on logical access control flaws is also recommended to identify similar bypasses in other endpoints that handle resource-specific operations.