GHSA-hh89-3r9w-qj3j: Npm/n8n vulnerability
Impact
The OAuth Dynamic Client Registration endpoints validated field sizes only for redirecturis, leaving clientname and granttypes 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 clientname at its column length and limits granttypes 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 oauthclients table for anomalous entries.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/n8nto a version that resolves this vulnerability.Fixed in 2.37.7 - Upgrade
Upgrade
npm/n8nto a version that resolves this vulnerability.Fixed in 2.38.2 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 2.37.7 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 2.38.2 - Compensating control
Place the n8n instance behind a reverse proxy configured to enforce strict request body size limits below the default 16 MiB.
- Compensating control
Restrict network access to the n8n instance so that only trusted clients can reach it.
- Operational
Monitor database size for unexpected growth and audit the oauth_clients table for anomalous entries.
Event History
Frequently Asked Questions
Who can exploit this issue?
Any unauthenticated remote caller that can reach the OAuth Dynamic Client Registration endpoints can submit oversized client_name or grant_types values. No account on the n8n instance is required.
Are default deployments affected?
The provided information identifies the affected endpoints but does not state whether OAuth Dynamic Client Registration is enabled or reachable in a default n8n deployment. Exposure depends on whether an untrusted network client can access those endpoints.
What is the impact of repeated exploitation?
Each malicious registration can persist arbitrarily large field values in the database. Repeated requests can cause unbounded persistent-storage growth, potentially consuming database capacity.
What should administrators do if they cannot upgrade immediately?
Restrict network access so only trusted clients can reach the instance, and use a reverse proxy with strict request-body limits below the default 16 MiB. Monitor database growth and audit the oauth_clients table for anomalous entries.
How can administrators check for signs of exploitation?
Review database size for unexpected growth and inspect the oauth_clients table for anomalous client registrations. The issue is fixed in n8n 2.37.7 and 2.38.2; upgrade to one of those versions or later.