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

The registration endpoints checked field size only for redirect_uris. client_name and grant_types had presence checks and nothing else. An unauthenticated caller could submit very large values for either and the instance wrote them to the database, into the oauth_clients table. No account is needed. Repeating the call grows storage without limit.

The practical result is disk or database exhaustion on the n8n host. Once storage is full, workflows can fail to run or save, executions are lost, and the instance may go down. Because n8n often runs automation that touches many connected services, the outage can stall business processes that depend on it.

The workaround notes mention a default request body limit of 16 MiB, which means each request can carry a large payload. The fix caps client_name at its column length, limits grant_types to the grant types the server implements, and caps the array at that count. The CVSS 4.0 vector rates availability as high only, with no confidentiality or integrity loss.

Affected: n8n before 2.37.7, and 2.38.0 and 2.38.1. Versions 2.37.7 and 2.38.2 and later are fixed. The instance must be reachable by the attacker over the network. Check your version:

n8n --version

For Docker, check the image tag you run. For npm installs: npm ls n8n.

Upgrade to n8n 2.37.7 or 2.38.2, or any later release.

npm install -g [email protected]

If you cannot upgrade at once, n8n lists these partial mitigations: restrict network access so only trusted clients reach the instance, put a reverse proxy in front with a request body limit below the 16 MiB default, and monitor database size and the oauth_clients table for odd entries. These do not remove the risk.

Watch database size for sudden growth. Query the oauth_clients table for rows with very large client_name or grant_types values, or a large count of rows created in a short time with no matching legitimate client. In access logs, look for repeated unauthenticated POSTs to the OAuth client registration endpoint, often with large bodies.

Impact

The OAuth Dynamic Client Registration endpoints validated field sizes only for redirect_uris, leaving client_name and grant_types bounded by presence checks alone. An unauthenticated remote caller could submit arbitrarily large values in either field and have them persisted to the database. Repeated registration therefore grew persistent storage without limit and without any account on the instance. The patch caps client_name at its column length and limits grant_types to the grant types the server actually implements, with the array capped at that count.

Patches

The issue has been fixed in n8n versions 2.37.7 and 2.38.2. Users should upgrade to one of these versions or later to remediate the vulnerability.

Workarounds

If upgrading is not immediately possible, administrators should consider the following temporary mitigations:

• Restrict network access to the n8n instance so that only trusted clients can reach it.
• Place the instance behind a reverse proxy configured to enforce strict request body size limits below the default 16 MiB.
• Monitor database size for unexpected growth and audit the oauth_clients table for anomalous entries.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.