CVE-2026-82753: Unauthenticated authorize requests create unbounded, never-expiring CIMD client rows and cache entries in ash_authentication_oauth2_server
Allocation of Resources Without Limits or Throttling vulnerability in ash-project ashauthenticationoauth2server allows an unauthenticated attacker to exhaust database storage and memory.
The /authorize endpoint is unauthenticated by design. With Client ID Metadata Documents enabled, resolveclient/3 in AshAuthentication.Oauth2Server.CIMD fetches the document for each new URL-shaped clientid and upserts a client row, with no cap on the number of rows, no expiry or garbage collection, and no length bound on the fetched fields; the document was also placed in CIMD.Cache before validation, so even rejected documents held cache memory until their TTL. An attacker serving valid documents at many distinct URLs creates one permanent client row per URL, each able to carry multi-megabyte strings, growing storage and memory without bound.
This issue affects ashauthenticationoauth2server: from 0.3.0 before 0.3.1.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ash-project/ash_authentication_oauth2_serverto a version that resolves this vulnerability.Fixed in 0.3.1 - Configuration
If present in your deployment, disable Client ID Metadata Documents to prevent resolve_client/3 from fetching/upserting unbounded URL-shaped client_id documents (and associated CIMD client rows/cache entries) without caps/expiry/length bounds.
ash-project ash_authentication_oauth2_server (CIMD) Client ID Metadata Documents = enabled - Compensating control
Add a compensating control to throttle or rate-limit unauthenticated traffic to the /authorize endpoint so an attacker cannot create unbounded client rows/cache entries via many distinct URL-shaped client_id values.
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Deployments using ash_authentication_oauth2_server versions from 0.3.0 before 0.3.1 are affected when Client ID Metadata Documents are enabled. The exposed endpoint is /authorize, which is unauthenticated by design.
What does an attacker need to do to trigger the resource exhaustion?
An attacker can send authorize requests using many distinct URL-shaped client_id values and serve valid metadata documents from those URLs. Each distinct URL can create a permanent client row, while large document fields can consume substantial database storage and memory.
Are rejected client metadata documents harmless?
No. The metadata document was placed in CIMD.Cache before validation, so rejected documents can still consume cache memory until the cache TTL expires. Valid documents are more severe because they also result in never-expiring client rows.
How can I determine whether exploitation may already have occurred?
Review client records created through CIMD for an unexpected number of distinct URL-based client IDs, especially records with unusually large field values. Also investigate abnormal database growth or cache-memory growth associated with requests to /authorize.