highAgent ThreatResource Exhaustion

n8n OAuth Dynamic Client Registration Unauthenticated Storage Exhaustion

First seen Sep 14, 2026 · Updated Sep 14, 2026

n8noauthdynamic-client-registrationunauthenticateddosstorage-exhaustionagent-orchestrationASI10 · Rogue AgentsSurface: ProtocolPropagation: None

n8n's OAuth Dynamic Client Registration endpoint failed to bound the size of the client_name and grant_types fields, allowing any unauthenticated remote caller to submit oversized payloads that get persisted to the database indefinitely. Repeated submissions can exhaust storage and degrade or crash the n8n instance, which is commonly used as an automation/orchestration layer for AI agent workflows. This is a straightforward denial-of-service issue rather than a prompt injection or agent-hijacking vulnerability.

Technical Analysis

The vulnerability lies in the OAuth Dynamic Client Registration (DCR) endpoint, a standard OAuth 2.0 mechanism often exposed to allow clients (including agentic tools/integrations) to self-register. Input validation only enforced size limits on redirect_uris while client_name and grant_types were checked for presence but not bounded length or cardinality, letting an attacker submit arbitrarily large strings/arrays. Because DCR is intentionally unauthenticated (to bootstrap OAuth clients), any remote actor can repeatedly call the endpoint, growing the oauth_clients table without limit and exhausting database/disk storage. In n8n deployments that back AI agent pipelines or MCP/tool integrations, this could disrupt automation, cascade into failures of dependent agents or workflows relying on the instance's availability, and serve as an entry point for broader denial-of-service against orchestration infrastructure.

Affected Systems

n8n; protocols: OAuth 2.0 Dynamic Client Registration

Detection Signatures

  • Unusually large or repeated POST requests to /oauth2/register or equivalent DCR endpoint from unauthenticated sources
  • Rapid, abnormal growth of the oauth_clients database table row count or size
  • client_name or grant_types field values exceeding expected/normal lengths in oauth_clients records
  • Spikes in disk/database storage utilization correlated with unauthenticated inbound traffic to n8n's OAuth registration path
  • Repeated registration requests from the same IP or IP range with minimal variation in payload structure

Remediation Steps

  1. 1

    Upgrade n8n

    Update to n8n version 2.37.7, 2.38.2, or later, which caps client_name to its column length and restricts grant_types to only the grant types implemented by the server.

  2. 2

    Restrict network exposure

    Limit access to the n8n instance and its OAuth endpoints to trusted networks or clients via firewall rules or VPN until patched.

  3. 3

    Enforce request size limits

    Deploy a reverse proxy (e.g., nginx, Envoy) in front of n8n with strict request body size limits well below the platform default of 16 MiB.

  4. 4

    Monitor storage and audit records

    Set up alerting on database/disk growth and periodically audit the oauth_clients table for anomalous or oversized entries.

  5. 5

    Rate limit registration endpoint

    Apply rate limiting per IP/client on the OAuth Dynamic Client Registration endpoint to prevent bulk automated abuse.

CVE / Advisory IDs

CVE-2026-86075GHSA-hh89-3r9w-qj3j

Industries Most Exposed

Software/TechnologyIT AutomationManaged Service ProvidersAny industry using n8n for workflow or AI agent orchestration

Sources

Respond to this threat

Pro subscribers get a full AI-generated incident-response playbook for this threat — detection, containment, eradication, and recovery steps — plus an unlimited AI Threat Advisor for questions about your environment.