CVE-2026-86075 in n8n
Summary
by MITRE • 09/09/2026
n8n is an open source workflow automation platform. Prior to 2.37.7 and 2.38.2, the OAuth Dynamic Client Registration endpoint bounded redirect_uris but accepted arbitrarily large client_name and grant_types values. An unauthenticated remote caller could repeatedly persist oversized values in oauth_clients and exhaust database storage. The affected validation is in packages/cli/src/modules/oauth-server/oauth-server.service.ts, including MAX_CLIENT_NAME_LENGTH and MAX_GRANT_TYPES. This issue is fixed in versions 2.37.7 and 2.38.2.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/09/2026
The vulnerability identified within the n8n workflow automation platform represents a significant resource exhaustion risk stemming from insufficient input validation on the OAuth Dynamic Client Registration endpoint. Prior to version 2.37.7 and 2.38.2, the system implemented bounds checking for redirect URIs but failed to enforce strict length limits on other critical fields such as client_name and grant_types. This inconsistency in validation logic allowed an unauthenticated remote attacker to submit arbitrarily large payloads during the dynamic client registration process. The specific code location responsible for this flaw resides within packages/cli/src/modules/oauth-server/oauth-server.service.ts, where constants like MAX_CLIENT_NAME_LENGTH and MAX_GRANT_TYPES were either not applied or improperly enforced against incoming requests from external actors.
From a technical perspective, this vulnerability is classified as an Improper Input Validation issue, aligning with CWE-20 in the Common Weakness Enumeration standard. The core mechanism of exploitation involves sending repeated registration requests containing excessively long strings for client_name and grant_types fields. Because these values are persisted directly into the oauth_clients database table without adequate size constraints, each request consumes a disproportionate amount of disk space relative to typical valid registrations. This behavior effectively transforms the OAuth endpoint from an authentication utility into a vector for Denial of Service attacks through storage exhaustion. The attacker does not require any prior credentials or session tokens, making this a remote unauthenticated attack surface that is easily exploitable by automated scripts.
The operational impact of this vulnerability centers on resource depletion and service availability degradation. As the database accumulates these oversized records, it can rapidly consume available disk space allocated to the n8n instance. Once storage limits are reached, the application may fail to write new data, leading to a complete halt in workflow execution capabilities. Furthermore, large record sizes can degrade query performance for existing OAuth operations, causing latency spikes or timeouts that affect legitimate users attempting to authenticate via dynamic client registration. In severe cases, if the underlying database engine does not handle oversized inserts gracefully, it could lead to database corruption or crash, requiring manual intervention and data recovery procedures to restore service continuity.
This scenario is also indicative of a potential impact on system integrity as defined by the MITRE ATT&CK framework under techniques related to Resource Hijacking or Denial of Service via application layer exhaustion. While not directly compromising confidentiality or integrity in the traditional sense, the ability to disrupt availability undermines the reliability of the automation platform for its intended users. The lack of rate limiting combined with weak input validation creates a compounding effect where even low-volume attacks can escalate quickly into high-impact outages if left unmitigated by infrastructure-level controls such as web application firewalls or reverse proxy size limits.
To mitigate this vulnerability, organizations running affected versions must immediately upgrade to n8n version 2.37.7 or later for the stable branch and 2.38.2 or later for the development branch. These releases include corrected validation logic that properly enforces maximum length constraints on client_name and grant_types fields during dynamic client registration. In environments where immediate patching is not feasible, administrators should implement network-level controls to restrict the size of HTTP request bodies directed at the OAuth endpoints. Additionally, deploying a Web Application Firewall with rules designed to block excessively large payloads can provide an effective layer of defense against this specific exploitation pattern until the software update is applied. Regular auditing of database storage usage and implementing alerts for rapid growth in record sizes can also aid in early detection of such abuse attempts.