EUVD-2026-112488Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as low-privilege confidential client
-
ExploitSubmit token request with spoofed client_id in body
-
ExecutionGrant and scope validation run under victim client identity
-
ImpactReceive token carrying unauthorized grants or scopes
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization logic validation
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | The attacker must possess valid credentials for one lower-privilege confidential client (authenticated, PR:L). The target must be an OAuthLib provider deployment prior to 4.0.0 exposing the client_credentials or password (Resource Owner Password Credentials) grant handlers, and a separate higher-privilege client with broader grants or scopes must exist. The decisive prerequisite is that the application's RequestValidator authorizes using the client_id argument passed to validate_grant_type() or validate_scopes() - the documented RequestValidator API. Limiting factor: deployments whose validators ignore client_id and authorize exclusively from request.client are not affected, and the attack cannot be performed unauthenticated. Authorization-code and other flows are outside the stated affected surface. |
| Impact | Signals are moderately consistent but incomplete. The vendor CVSS 4.0 score of 8.4 (High) and the vector CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N indicate a network-reachable, low-complexity flaw that requires an already-authenticated low-privilege client (PR:L), with high integrity impact on both the vulnerable and subsequent systems (VI:H, SC:H, SI:H) - consistent with the CWE-863 improper-authorization classification and the advisory text. The vuln.today decision label is 'this_week' (priority, not act_now/emergency). No EPSS score and no KEV listing are present in the input, so there is no quantified exploitation-probability signal and no evidence of active in-the-wild exploitation. A full reproduction script is published inside the GHSA advisory, so a public PoC reference exists; it is not verified as working exploit code in the input. The most important risk modulator is conditional: exploitation only yields unauthorized grants/scopes when the application's RequestValidator authorizes from the documented client_id argument (the supported API) - deployments whose validators authorize only from request.client are not affected. This makes the real-world severity deployment-dependent rather than universal, so this is a genuine priority for OAuthLib-based OAuth2 providers but not a blanket critical for every OAuthLib install. Missing data: no EPSS, no KEV, and no independent confirmation of exploitation prevalence. |
| Exploit ScenarioDerived | An attacker who holds valid credentials for one low-privilege confidential client authenticates normally against an OAuthLib-based OAuth2 token endpoint, but places a different, higher-privileged client_id in the token request body. Because OAuthLib keeps the attacker-supplied client_id and passes it to validate_grant_type() and validate_scopes() while the authenticated client object remains the low-privilege one, a validator that authorizes by the client_id argument issues a token with the victim client's grants or scopes (e.g., 'admin'). A full reproduction script demonstrating this for both client_credentials and password grants is included in the GHSA advisory. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 28, 2026
Client identity spoofing in OAuthLib before 4.0.0 allows an authenticated, lower-privilege confidential client to have its grant type and scope checks evaluated against a different, higher-privilege client's ID, potentially yielding access tokens carrying grants and scopes that were never assigned to it. The flaw exists in the client_credentials and Resource Owner Password Credentials token grant handlers, where the authenticated client object is stored in request.client but an attacker-supplied client_id from the request body is retained and passed as the first-class client_id argument to validate_grant_type() and validate_scopes(). Only deployments whose RequestValidator authorizes from that client_id argument are exposed; validators that authorize exclusively from request.client are not affected, and the attack cannot be performed unauthenticated, so practical exposure is limited to providers that host multiple clients with differing privilege levels. Fixed in version 4.0.0; the upstream GitHub advisory (GHSA-7984-qgvg-3j9c) includes a public proof-of-concept reproducer script against oauthlib 3.3.1, and there is no CISA KEV listing or confirmed in-the-wild exploitation in the supplied intelligence.
RemediationAI
Upgrade to oauthlib 4.0.0, which is the vendor-released fix (https://github.com/oauthlib/oauthlib/releases/tag/v4.0.0), delivered via PR https://github.com/oauthlib/oauthlib/pull/920 and commit https://github.com/oauthlib/oauthlib/commit/c951a1d09f99f14e3240973fa83c4f4287d4753d; the advisory is at https://github.com/oauthlib/oauthlib/security/advisories/GHSA-7984-qgvg-3j9c. The fix makes the handlers compare request.client_id with request.client.client_id and raise a ServerError on any mismatch rather than silently normalizing it, so after upgrading, audit any OAuth clients that send client_id in the token request body alongside HTTP Basic or other client authentication - those requests will now fail and the clients must be corrected to omit the redundant parameter, otherwise legitimate token issuance breaks. Pending the upgrade, the effective compensating control is in application code: modify RequestValidator.validate_grant_type() and validate_scopes() to ignore the passed client_id argument and authorize solely from request.client.client_id, or add an explicit guard rejecting the request when request.client_id differs from request.client.client_id; this closes the bypass but deviates from the documented RequestValidator contract and requires re-review of validators that legitimately rely on the client_id argument (for example public-client paths). Deployments whose validators already authorize only from request.client are described as not affected and can treat the upgrade as maintaining that posture rather than as an emergency code change.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
OAuthlib is a Python implementation of OAuth 1 and OAuth 2 request-signing and provider logic (package pip/oauthlib; CPE cpe:2.3:a:oauthlib:oauthlib, version-agnostic wildcard covering all releases before 4.0.0). The root cause is CWE-863, Incorrect Authorization: an identity split between the authenticated principal and the principal used for authorization decisions. When OAuthlib's Request object parses the token request body, any client_id parameter becomes request.client_id. The documented RequestValidator.authenticate_client() contract has the integrator authenticate the client and set request.client; OAuthlib then checks that request.client has a client_id, but for the client_credentials and password/ROPC grant handlers it only fills request.client_id from request.client.client_id when the value is missing (request.client_id = request.client_id or request.client.client_id). Because OAuthlib's own body-supplied value survives, the shared grant helper in oauthlib/oauth2/rfc6749/grant_types/base.py calls validate_grant_type(request.client_id, ...) and validate_scopes(request.client_id, ...) with the attacker-controlled identifier while separately handing the genuine authenticated client object as a distinct argument - producing request.client.client_id "low" alongside request.client_id "high". The point of failure is therefore not authentication but the authorization inputs handed to application callbacks. The 4.0.0 fix (PR #920, commit c951a1d09f99f14e3240973fa83c4f4287d4753d) factors client authentication into validate_client_confidential()/validate_client_public() helpers that explicitly compare request.client_id against request.client.client_id and raise a ServerError on any discrepancy, and routes the authorization_code, client_credentials, refresh_token and ROPC handlers through them. Independent assessment scores this CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N (scope change reflecting impact on other clients' tokens); the supplied CVSS 4.0 vector is 8.4 with VI:H/SC:H/SI:H. Authorization-code and other flows fall outside the stated affected surface.
Know when Oauthlib gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:H/SI:H/SA:N
Network token endpoint (AV:N/AC:L); attacker must hold low-privilege client credentials (PR:L); authz-server flaw grants another client's scopes to protected resources, so S:C with C:H/I:H.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
2DescriptionCVE.org
OAuthLib is an implementation of the OAuth request-signing logic for Python 3.6+. Prior to 4.0.0, the client_credentials and Resource Owner Password Credentials token grant handlers can authenticate request.client as one confidential client while retaining an attacker-supplied request.client_id for validate_grant_type and validate_scopes. A lower-privilege authenticated client can therefore cause grant and scope authorization to use another client's identity when an application validator relies on the documented client_id argument, potentially issuing tokens with unauthorized grants or scopes. Validators that authorize exclusively from request.client may not be affected. This issue is fixed in version 4.0.0.
Technical POC Analysis
CWE-863 (incorrect authorization).
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
A high-severity vulnerability in OAuthLib (before 4.0.0) allows an authenticated, lower-privilege OAuth client to escalate its privileges by spoofing a higher-privilege client's ID during token requests. This impacts organizations running OAuth providers that host multiple clients with different privilege levels, potentially enabling unauthorized access to sensitive resources and data. Leadership should prioritize remediation because exploitation could lead to data breaches and compliance violations.
No vendor-released patch identified at time of analysis. Interim mitigations: ensure RequestValidator implementations authorize based solely on request.client (not the client_id argument), restrict token grant types to trusted clients, and monitor for anomalous client credential usage. Apply vendor patch when available.
Threat Intelligence Overview
NVD
CVE.org
GitHub
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
Exploit-DB