CVE-2026-86075: Unauthenticated Persistent Storage Exhaustion via OAuth Dynamic Client Registration Endpoint in n8n

The OAuth Dynamic Client Registration service in n8n provides a mechanism for client applications to dynamically register with the built-in OAuth 2.0 server. This endpoint is designed to receive external payloads containing client metadata, such as redirection URIs, client names, and desired grant types. By design, Dynamic Client Registration endpoints are exposed publicly without requiring pre-existing authentication, representing a high-exposure attack surface.

In vulnerable configurations, n8n fails to adequately restrict the size and boundaries of registration parameters. While certain critical security fields, like redirection URIs, undergo format and structure validation, secondary properties do not. This exposes the backend to arbitrary data injection.

The vulnerability is classified under CWE-770 (Allocation of Resources Without Limits or Throttling). This security issue allows unauthenticated remote attackers to send excessively large payloads to the platform. By repeatedly calling the registration service, attackers can exhaust the server storage and crash the service.

The root cause of CVE-2026-86075 lies within the handling of registration parameters in packages/cli/src/modules/oauth-server/oauth-server.service.ts. Specifically, during the parsing of dynamic client registration requests, the service does not enforce length constraints on the client_name string or the number of items within the grant_types array.

When a client application submits a dynamic registration request, the service extracts the metadata fields and passes them to the database layer. Because the backend validation only checks for the existence of required fields rather than their maximum permissible lengths, extremely long character strings are accepted without truncation or rejection.

The input data is subsequently persisted directly into the oauth_clients table of the underlying database system, such as SQLite, PostgreSQL, or MySQL. Since there are no throttles, rate limits, or physical payload restrictions on this registration path, an attacker can transmit multi-megabyte payloads in a continuous loop, causing rapid table inflation and eventual storage exhaustion.

The vulnerable implementation processes dynamic client registration parameters directly without applying validation checks on the payload sizes of client_name and grant_types. The following conceptual diagram represents the flow of input processing prior to database serialization:

In the vulnerable version, the incoming registration service receives raw input. The following code demonstrates the lack of length checks on fields prior to saving the client metadata:

// VULNERABLE CODE
async registerClient(registrationPayload: RegisterClientDto) {
  // Only redirect_uris format is strictly verified
  this.validateRedirectUris(registrationPayload.redirect_uris);
 
  // client_name and grant_types are saved without length constraints
  const newClient = this.oauthClientRepository.create({
    name: registrationPayload.client_name,
    grantTypes: registrationPayload.grant_types,
    redirectUris: registrationPayload.redirect_uris,
  });
 
  return await this.oauthClientRepository.save(newClient);
}

To resolve this issue, the patch enforces strict length limitations. The constants MAX_CLIENT_NAME_LENGTH and maximum element counts on grant_types have been integrated to validate the boundaries of incoming metadata properties:

// PATCHED CODE
import { MAX_CLIENT_NAME_LENGTH, MAX_GRANT_TYPES } from './constants';
 
async registerClient(registrationPayload: RegisterClientDto) {
  this.validateRedirectUris(registrationPayload.redirect_uris);
 
  // Added boundary validation for client_name length
  if (registrationPayload.client_name && registrationPayload.client_name.length > MAX_CLIENT_NAME_LENGTH) {
    throw new BadRequestError('Client name exceeds maximum allowed length');
  }
 
  // Added boundary validation for grant_types elements
  if (registrationPayload.grant_types && registrationPayload.grant_types.length > MAX_GRANT_TYPES) {
    throw new BadRequestError('Too many grant types provided');
  }
 
  const newClient = this.oauthClientRepository.create({
    name: registrationPayload.client_name,
    grantTypes: registrationPayload.grant_types,
    redirectUris: registrationPayload.redirect_uris,
  });
 
  return await this.oauthClientRepository.save(newClient);
}

Exploitation of CVE-2026-86075 requires network-level access to the exposed OAuth client registration endpoint of an n8n instance. Because the endpoint complies with dynamic registration specifications, it does not require prior authentication or API tokens.

An attacker can execute a denial of service attack by constructing automated scripts to send high volumes of HTTP POST requests containing oversized parameter payloads. By generating large blocks of repetitive characters inside the client_name attribute and specifying nested objects or arrays within grant_types, the size of each request can be increased to several megabytes.

As n8n receives these requests, it serializes each entry into the physical database. Over multiple parallel connections, this continuous influx of large records rapidly consumes available disk space, leading to write failures, application slowdowns, and ultimately an unrecoverable system crash.

The security impact of CVE-2026-86075 is classified as High with a CVSS v4.0 base score of 8.7. The primary threat is directed at system availability. Complete exhaustion of persistent storage prevents n8n from logging executions, storing session states, or running scheduled workflows.

Because n8n relies on database storage to track state transitions and save historical logs, database write locks or disk space exhaustion will freeze all running workflows. In enterprise environments where n8n coordinates critical business automation, this results in extensive operational downtime.

The confidentiality and integrity of existing data are not directly compromised by this vulnerability. However, the resulting service outage requires manual administrative intervention, such as clearing the affected database records or resizing the physical storage volumes, to restore system functionality.

The recommended remediation for this vulnerability is to upgrade the n8n application to a patched version immediately. For deployments on the 2.37.x branch, users must upgrade to version 2.37.7 or later. For deployments on the 2.38.x branch, users must upgrade to version 2.38.2 or later.

In environments where immediate upgrading is not possible, organizations should implement temporary mitigations at the network layer. Administrators can configure a Web Application Firewall (WAF) or reverse proxy to enforce a strict body size limit (e.g., maximum 10KB) on requests targeting the /oauth/register or similar OAuth endpoints.

Additionally, rate-limiting rules should be applied on these registration endpoints. Limiting the number of client registrations permitted per source IP address over a given time window can prevent automated storage-bloat attempts from causing system-wide service disruption.