CVE-2026-110843 in n8n
Summary
by MITRE • 10/15/2026
n8n before 2.41.4 and 2.42.x before 2.42.1 contains an uncontrolled resource consumption vulnerability in the unauthenticated OAuth authorize endpoint, which resolves clients by URL path but stores the caller's raw identifier as the record key. Unauthenticated attackers can send identifiers differing only in their query string to create unlimited first-party client records that bypass the registration cap, growing the database until the disk fills.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified in n8n versions prior to 2.41.4 and version 2.42.x prior to 2.42.1 represents a critical uncontrolled resource consumption flaw within the application's OAuth authorization infrastructure. This issue specifically targets the unauthenticated OAuth authorize endpoint, which is responsible for initiating the authentication flow by resolving client applications based on parameters provided in the request URL path. The core technical deficiency lies in how the system handles and stores these resolved clients. Instead of normalizing or validating the input to ensure uniqueness against existing records through a robust lookup mechanism, the application uses the caller's raw identifier as the direct key for database storage operations. This design choice creates a significant logical gap where distinct URL paths that differ only by their query string parameters are treated as entirely separate entities rather than variations of the same client identity.
From an operational perspective, this architectural flaw allows unauthenticated attackers to exploit the system by sending a high volume of requests with identifiers that vary solely in their query strings. Because each unique raw identifier is stored as a new first-party client record without proper deduplication or adherence to registration caps, an attacker can generate unlimited entries in the database. This process effectively bypasses any intended limits on the number of clients that can be registered within the system. The consequence is a rapid and unbounded growth of the underlying database storage requirements. As the attacker continues to send these crafted requests, the database expands continuously until it consumes all available disk space on the hosting server or cloud instance.
The impact of this vulnerability extends beyond simple resource exhaustion. Once the disk fills up due to the accumulation of malicious client records, the n8n application becomes unavailable, leading to a complete denial of service for legitimate users and workflows dependent on the platform. This scenario aligns with CWE-400, which describes uncontrolled resource consumption, as well as CWE-770, regarding allocation of resources without limits or thresholds. In terms of attack classification under the MITRE ATT&CK framework, this behavior is consistent with T1496 Resource Hijacking, specifically through cloud infrastructure abuse where an attacker consumes computational or storage resources to disrupt service availability. The lack of input validation and normalization on the OAuth endpoint further highlights a failure in secure coding practices related to data integrity and system resilience against automated abuse.
To mitigate this vulnerability, it is imperative for administrators running affected versions of n8n to upgrade immediately to version 2.41.4 or later, including any subsequent releases within the 2.42.x branch that are equal to or greater than 2.42.1. These updated versions address the underlying logic error by implementing proper normalization and deduplication mechanisms for client identifiers during the OAuth resolution process. Until an upgrade is performed, organizations should consider deploying web application firewalls with rules designed to detect and rate-limit excessive requests targeting the OAuth authorize endpoint, particularly those exhibiting patterns of high variability in query string parameters while maintaining consistent path structures. Additionally, monitoring database storage metrics can provide early warning signs of such abuse, allowing for manual intervention if automated protections are not yet in place.