CVE-2026-110852 in n8n
Summary
by MITRE • 10/15/2026
n8n before 1.123.83, 2.x before 2.41.4, and 2.42.x before 2.42.1 contains an authentication bypass because dynamic-path webhook resolution matched requests on the path alone, ignoring the server-generated identifier that is the URL's only unguessable component. Unauthenticated attackers can omit this identifier in requests to webhook, form, or MCP routes to execute workflows in unrelated projects under those projects' credentials.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified in n8n versions prior to 1.123.83, 2.x before 2.41.4, and 2.42.x before 2.42.1 represents a critical authentication bypass rooted in flawed input validation logic within the webhook resolution mechanism. This flaw specifically affects how the application processes incoming HTTP requests directed at dynamic-path webhooks, forms, and MCP routes. The core technical deficiency lies in the server's reliance on the URL path structure to identify which workflow should be executed upon receiving an external trigger. In a secure implementation of such systems, each webhook endpoint is typically assigned a unique, cryptographically strong identifier that serves as the sole unguessable component required for authentication and authorization. However, due to this vulnerability, the application fails to validate or require this specific server-generated identifier when resolving dynamic paths. Instead, it matches incoming requests based solely on the static portion of the URL path, effectively ignoring the critical security token embedded in the full request URI.
This architectural oversight allows unauthenticated attackers to bypass authentication controls entirely by omitting the required unique identifier from their HTTP requests. By constructing a malicious payload that targets only the predictable segments of the webhook URL, an attacker can successfully trigger workflows without possessing valid credentials or API keys. The operational impact of this flaw is severe, as it enables unauthorized execution of automation logic under the context and permissions of the affected project. This means that any workflow configured to perform sensitive operations—such as accessing databases, sending emails, interacting with external APIs, or modifying system configurations—can be executed by an adversary without detection or authorization. The attacker gains the ability to leverage the trust relationship between n8n and its connected services, potentially leading to data exfiltration, unauthorized modifications of business logic, or further lateral movement within the organization's infrastructure depending on the capabilities granted to the compromised workflow credentials.
From a classification perspective, this vulnerability aligns with CWE-287, which denotes Improper Authentication, as the system fails to adequately verify the identity of users attempting to access resources. Furthermore, it relates closely to CWE-640, Weak Password Recovery Mechanisms for Administrators, in the broader context of relying on obscurity rather than robust cryptographic verification for security controls. In terms of offensive tactics, this exploit maps directly to MITRE ATT&CK technique T1505.003, Server Software Component: Web Hook, where adversaries register or abuse webhooks to execute code remotely. The ability to trigger workflows in unrelated projects under their credentials also touches upon privilege escalation concepts found in CWE-269, Improper Privilege Management, as the attacker assumes the identity and permissions of a legitimate service account associated with the target workflow.
To mitigate this risk, organizations running affected versions of n8n must immediately upgrade to version 1.123.83 or later for the v1 branch, version 2.41.4 or later for the v2.x stable branch, and version 2.42.1 or later for the v2.42.x release line. These updates contain patches that enforce strict validation of the server-generated unique identifier during webhook resolution, ensuring that requests lacking this critical component are rejected before any workflow logic is executed. In addition to upgrading, administrators should review their existing webhooks and forms to ensure no legacy configurations rely on predictable or static identifiers for security purposes. Implementing network-level access controls such as IP whitelisting can provide an additional layer of defense in depth, although it does not replace the need for proper application-layer authentication. Regular auditing of webhook endpoints and monitoring logs for unusual execution patterns related to dynamic paths will also help detect any potential exploitation attempts that may have occurred prior to remediation.