CVE-2026-86075: n8n unauth OAuth DCR fields exhaust

Q: Is CVE-2026-86075 actively exploited?

No confirmed active exploitation of CVE-2026-86075 has been reported, but organizations should still patch proactively.

Q: How to fix CVE-2026-86075?

Upgrade to n8n 2.37.7 (2.37.x branch) or 2.38.2 (2.38.x branch) immediately, both of which enforce MAX_CLIENT_NAME_LENGTH and MAX_GRANT_TYPES limits in packages/cli/src/modules/oauth-server/oauth-server.service.ts. If immediate patching isn't possible, restrict network access to the OAuth Dynamic Client Registration endpoint (deny anonymous internet access, allow-list known OAuth integrators) and add a reverse-proxy or WAF request-body-size cap as a stopgap. For detection, monitor oauth_clients table row count and total size for abnormal growth, alert on repeated registration requests from a single source IP, and check database disk-utilization alarms that may already be in place. After patching, audit existing oauth_clients rows for any pre-patch oversized client_name/grant_types entries and purge them to reclaim storage.

Q: What systems are affected by CVE-2026-86075?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow automation / orchestration platforms.

Q: What is the CVSS score for CVE-2026-86075?

No CVSS score has been assigned yet.

CISO Take

n8n's OAuth Dynamic Client Registration endpoint capped redirect_uris but left client_name and grant_types unbounded, so any unauthenticated caller could repeatedly register oauth_clients records padded with oversized strings and fill up the underlying database. There's no CVSS score, no EPSS data, no CISA KEV listing, and no public exploit or Nuclei template yet, so this looks like a self-reported hardening fix rather than an actively exploited bug — but the trigger requires zero authentication and zero AI/ML expertise, which keeps exploitability high even without those signals. n8n sits in the ai_agent category of our taxonomy because it's widely used to orchestrate LLM calls and agentic workflows, so a storage-exhaustion DoS here doesn't leak model data or hijack an agent, but it can take down the automation platform those AI workflows depend on, including any breaking-alert or compliance pipelines built on it. Patch to n8n 2.37.7 or 2.38.2 immediately; until then, front the OAuth DCR endpoint with a WAF rule or reverse-proxy body-size limit, and monitor oauth_clients row counts / table size for anomalous growth as a detection signal.

Sources: NVD GitHub Advisory ATLAS

What is the risk?

This is a classic uncontrolled resource consumption flaw (CWE-770) reachable pre-authentication, which maximizes exploitability — no credentials, no user interaction, no special tooling required, just repeated HTTP POSTs with oversized fields. The ceiling on impact is availability, not confidentiality or integrity: an attacker cannot read data, tamper with workflows, or pivot into the AI agent logic itself, they can only degrade or crash the n8n instance by starving its database. Absent CVSS/EPSS scoring and KEV listing, real-world exploitation activity is unconfirmed, but the low barrier to entry means opportunistic scanning against internet-exposed n8n instances is plausible once the advisory is public. Overall risk is high for any internet-facing, unpatched n8n deployment and low for instances that sit behind authentication or network controls that block anonymous access to the OAuth endpoints.

How does the attack unfold?

Entry point

Attacker locates an internet-exposed n8n instance and reaches its unauthenticated OAuth Dynamic Client Registration endpoint.

AML.T0049

Exploitation

Attacker submits repeated registration requests with oversized client_name and grant_types values that bypass the missing length checks.

Resource exhaustion

Each request persists an oversized row into the oauth_clients table, progressively consuming database storage.

Impact

Database storage fills up, causing write failures across the n8n instance and denying service to all workflows and AI agent automations it hosts.

AML.T0029

Entry point

Attacker locates an internet-exposed n8n instance and reaches its unauthenticated OAuth Dynamic Client Registration endpoint.

AML.T0049

Exploitation

Attacker submits repeated registration requests with oversized client_name and grant_types values that bypass the missing length checks.

Resource exhaustion

Each request persists an oversized row into the oauth_clients table, progressively consuming database storage.

Impact

Database storage fills up, causing write failures across the n8n instance and denying service to all workflows and AI agent automations it hosts.

AML.T0029

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
n8n	npm	>= 2.38.0, < 2.38.2	`2.38.2`
204.1K OpenSSF 6.6 16 dependents Pushed 7d ago 53% patched ~5d to patch Full package profile →

Do you use n8n? You're affected.

How severe is it?

CVSS 3.1

N/A

EPSS

0.3%

chance of exploitation in 30 days

Higher than 27% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

What should I do?

1 step

Upgrade to n8n 2.37.7 (2.37.x branch) or 2.38.2 (2.38.x branch) immediately, both of which enforce MAX_CLIENT_NAME_LENGTH and MAX_GRANT_TYPES limits in packages/cli/src/modules/oauth-server/oauth-server.service.ts. If immediate patching isn't possible, restrict network access to the OAuth Dynamic Client Registration endpoint (deny anonymous internet access, allow-list known OAuth integrators) and add a reverse-proxy or WAF request-body-size cap as a stopgap. For detection, monitor oauth_clients table row count and total size for abnormal growth, alert on repeated registration requests from a single source IP, and check database disk-utilization alarms that may already be in place. After patching, audit existing oauth_clients rows for any pre-patch oversized client_name/grant_types entries and purge them to reclaim storage.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable Yes

Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

DoS Agent API AML.T0029 - Denial of AI Service AML.T0049 - Exploit Public-Facing Application

Which compliance frameworks are affected?

This CVE is relevant to:

NIST AI RMF

MEASURE 2.7 - AI system security and resilience are evaluated and documented

OWASP LLM Top 10

LLM10:2025 - Unbounded Consumption

Frequently Asked Questions

What is CVE-2026-86075?

n8n's OAuth Dynamic Client Registration endpoint capped redirect_uris but left client_name and grant_types unbounded, so any unauthenticated caller could repeatedly register oauth_clients records padded with oversized strings and fill up the underlying database. There's no CVSS score, no EPSS data, no CISA KEV listing, and no public exploit or Nuclei template yet, so this looks like a self-reported hardening fix rather than an actively exploited bug — but the trigger requires zero authentication and zero AI/ML expertise, which keeps exploitability high even without those signals. n8n sits in the ai_agent category of our taxonomy because it's widely used to orchestrate LLM calls and agentic workflows, so a storage-exhaustion DoS here doesn't leak model data or hijack an agent, but it can take down the automation platform those AI workflows depend on, including any breaking-alert or compliance pipelines built on it. Patch to n8n 2.37.7 or 2.38.2 immediately; until then, front the OAuth DCR endpoint with a WAF rule or reverse-proxy body-size limit, and monitor oauth_clients row counts / table size for anomalous growth as a detection signal.

Is CVE-2026-86075 actively exploited?

No confirmed active exploitation of CVE-2026-86075 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-86075?

Upgrade to n8n 2.37.7 (2.37.x branch) or 2.38.2 (2.38.x branch) immediately, both of which enforce MAX_CLIENT_NAME_LENGTH and MAX_GRANT_TYPES limits in packages/cli/src/modules/oauth-server/oauth-server.service.ts. If immediate patching isn't possible, restrict network access to the OAuth Dynamic Client Registration endpoint (deny anonymous internet access, allow-list known OAuth integrators) and add a reverse-proxy or WAF request-body-size cap as a stopgap. For detection, monitor oauth_clients table row count and total size for abnormal growth, alert on repeated registration requests from a single source IP, and check database disk-utilization alarms that may already be in place. After patching, audit existing oauth_clients rows for any pre-patch oversized client_name/grant_types entries and purge them to reclaim storage.

What systems are affected by CVE-2026-86075?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow automation / orchestration platforms.

What is the CVSS score for CVE-2026-86075?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksworkflow automation / orchestration platforms

MITRE ATLAS Techniques

AML.T0029 Denial of AI Service

AML.T0049 Exploit Public-Facing Application

Compliance Controls Affected

NIST AI RMF: MEASURE 2.7

OWASP LLM Top 10: LLM10:2025

What are the technical details?

Original Advisory

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.

Exploitation Scenario

An adversary scans the internet for exposed n8n instances and identifies one running a pre-2.37.7/2.38.2 version with its OAuth Dynamic Client Registration endpoint reachable without authentication. They script repeated POST requests to that endpoint, each carrying a client_name and grant_types field padded to several megabytes, since only redirect_uris was length-bounded. Each request persists a new oversized row in the oauth_clients table; run at scale (or looped over hours), this fills the database's allocated storage, causing writes to fail across the entire n8n instance — including workflow executions, credential updates, and any AI agent pipelines the instance orchestrates. The organization experiences an availability outage of its automation platform with no warning beyond disk-space alerts, and recovery requires purging the malicious rows and provisioning additional storage before service resumes.

Weaknesses (CWE)

CWE-770 Allocation of Resources Without Limits or Throttling Primary CWE-770 Allocation of Resources Without Limits or Throttling Primary CWE-770 Allocation of Resources Without Limits or Throttling

CWE-770 — Allocation of Resources Without Limits or Throttling: The product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated.

[Requirements] Clearly specify the minimum and maximum expectations for capabilities, and dictate which behaviors are acceptable when resource allocation reaches limits.
[Architecture and Design] Limit the amount of resources that are accessible to unprivileged users. Set per-user limits for resources. Allow the system administrator to define these limits. Be careful to avoid CWE-410.

Source: MITRE CWE corpus.