n8n OAuth Dynamic Client Registration Unauthenticated Storage Exhaustion
First seen Sep 14, 2026 · Updated Sep 14, 2026
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
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
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
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
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
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
Industries Most Exposed
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.