CVE-2026-86075: n8n Workflow Automation Platform DOS Vulnerability

CVE-2026-86075 Overview

CVE-2026-86075 is a resource exhaustion vulnerability in n8n, an open source workflow automation platform. The flaw resides in the OAuth Dynamic Client Registration endpoint, which validates redirect_uris length but fails to bound client_name and grant_types values. Unauthenticated remote callers can repeatedly submit oversized values that persist to the oauth_clients database table. Repeated submissions exhaust database storage and degrade platform availability. The vulnerability affects n8n releases prior to 2.37.7 and 2.38.2, and is tracked under [CWE-770: Allocation of Resources Without Limits or Throttling].

Critical Impact
An unauthenticated attacker can exhaust database storage on an internet-exposed n8n instance, causing a denial-of-service condition affecting all workflow automation operations.

Affected Products

n8n versions prior to 2.37.7 (2.37.x branch)
n8n versions prior to 2.38.2 (2.38.x branch)
Self-hosted n8n deployments exposing the OAuth Dynamic Client Registration endpoint

Discovery Timeline

2026-09-08 - CVE-2026-86075 published to NVD
2026-09-09 - Last updated in NVD database

Technical Details for CVE-2026-86075

Vulnerability Analysis

The vulnerability exists in the OAuth 2.0 Dynamic Client Registration handler implemented in packages/cli/src/modules/oauth-server/oauth-server.service.ts. The endpoint accepts client registration requests without authentication, as required by the OAuth Dynamic Client Registration Protocol (RFC 7591).

The service enforces length validation on the redirect_uris parameter but omits equivalent constraints on client_name and grant_types. An attacker can supply arbitrarily large strings or arrays for these fields, and the values are persisted to the oauth_clients table in the backing database. Repeated calls cumulatively consume storage until the database runs out of space.

The fix in versions 2.37.7 and 2.38.2 introduces two constants, MAX_CLIENT_NAME_LENGTH and MAX_GRANT_TYPES, applied during input validation before persistence.

Root Cause

The root cause is missing input validation on user-controlled fields written to persistent storage. The registration handler trusted client-supplied metadata sizes without bounding them, violating the principle of validating all untrusted input before database writes.

Attack Vector

The attack requires only network access to an n8n instance exposing the OAuth server module. The attacker sends repeated HTTP POST requests to the Dynamic Client Registration endpoint, each containing oversized client_name strings or oversized grant_types arrays. No authentication, user interaction, or elevated privileges are required. Each successful request writes attacker-controlled data to oauth_clients, and the cumulative writes exhaust database storage.

Refer to the GitHub Security Advisory GHSA-hh89-3r9w-qj3j for the vendor's technical description.

Detection Methods for CVE-2026-86075

Indicators of Compromise

Unusual growth in the size of the oauth_clients database table without corresponding legitimate integration activity
Repeated HTTP POST requests to the OAuth Dynamic Client Registration endpoint from a single or small set of source IP addresses
Registered OAuth clients with abnormally long client_name fields or extensive grant_types arrays
Database storage alerts or disk-full errors on the n8n backend datastore

Detection Strategies

Query the oauth_clients table for rows where client_name length exceeds expected values or grant_types contains atypical entries
Enable web application firewall (WAF) or reverse-proxy logging on the OAuth registration endpoint and alert on request body sizes above a reasonable threshold
Correlate registration request volume against baseline traffic to surface volumetric abuse

Monitoring Recommendations

Configure database storage utilization alerts with thresholds well below capacity to allow response time
Track HTTP request rates by endpoint and source IP against the OAuth server module
Review OAuth client registrations on a scheduled basis and remove entries that do not correspond to known integrations

How to Mitigate CVE-2026-86075

Immediate Actions Required

Upgrade n8n to version 2.37.7 or 2.38.2, depending on the deployed release branch
Restrict network exposure of the OAuth Dynamic Client Registration endpoint to trusted networks where feasible
Audit the oauth_clients table and delete entries containing oversized client_name or grant_types values
Verify database storage capacity and reclaim space consumed by malicious registrations

Patch Information

The vendor released fixes in n8n 2.37.7 and n8n 2.38.2. The patched validation logic in packages/cli/src/modules/oauth-server/oauth-server.service.ts enforces MAX_CLIENT_NAME_LENGTH and MAX_GRANT_TYPES limits before writing to the database.

Workarounds

Place a reverse proxy or WAF in front of n8n and enforce request body size limits on the OAuth registration path
Apply rate limiting per source IP on the Dynamic Client Registration endpoint
Disable the OAuth server module if it is not required for the deployment
Implement database-level quotas or row-size constraints on the oauth_clients table where supported

bash

# Configuration example
# Upgrade n8n via npm
npm install -g n8n@2.38.2

# Or upgrade via Docker
docker pull n8nio/n8n:2.38.2
docker stop n8n && docker rm n8n
docker run -d --name n8n -p 5678:5678 n8nio/n8n:2.38.2