OAuthLib CVE-2026-49272

The target must use oauthlib's RFC 8628 DeviceCodeGrant at its token endpoint (oauthlib 3.3.0 through pre-4.0.0). The attacker must know a valid client_id that is registered and enabled for the device_code grant; no valid device_code is needed because it is not validated. The advisory's PoC additionally requires the integrator's RequestValidator.authenticate_client to return success for public clients (set grant_type to urn:ietf:params:oauth:grant-type:device_code and client_type 'public'), which is linked to the separate oauthlib issue #919. Limiting factors: deployments not using the device code workflow are unaffected; exploitation realistically depends on the public-client authentication behavior described above and on the attacker obtaining a valid device-enabled client ID; the only complete fix per the vendor is upgrading to 4.0.0.

The vendor-assigned CVSS is 8.5 (High) with vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:N, reflecting a network-reachable authentication bypass that yields a bearer token. However, the real-world risk is narrower than the raw score suggests and depends heavily on how the library is integrated. The vulnerability (CWE-287) is confirmed by the vendor advisory GHSA-3jp2-3mrg-2vxc: DeviceCodeGrant.validate_token_request performs no validation of the device_code parameter, so a caller who knows a valid client ID enabled for the device workflow can mint a token with a bogus device_code. No EPSS score was provided and the CVE is not listed in CISA KEV, so there is no evidence of active or widespread exploitation; the vuln.today decision label is 'this_week' (not act_now/emergency), consistent with a patch-this-cycle priority rather than a fire drill. A detailed public PoC is documented in the advisory, but the input does not confirm it as working exploit code. A key nuance: the advisory's PoC only reaches the vulnerable path when the integrator's authenticate_client implementation accepts public clients (tied to the separate oauthlib issue #919), so the input's AC:L/PR:L rating understates a real configuration dependency - exploitation is realistic but conditioned on specific integrator behavior rather than a default remote-unauthenticated break. Treat as a genuine priority for any deployment using the RFC 8628 device workflow on oauthlib 3.3.0-3.x, while recognizing the dependency makes it closer to a targeted than a mass-exploitable issue.

An attacker who learns a valid client ID that is enabled for the device code workflow sends a token-endpoint request using grant_type urn:ietf:params:oauth:grant-type:device_code and an arbitrary device_code value; because the device_code is never validated, the server returns a valid bearer token for that client, which the attacker then uses to access protected resources as the impersonated client. A detailed PoC walkthrough is published in the vendor advisory, though the input does not confirm it as verified working exploit code. The CVSS AC:L/PR:L rating reflects network reachability, but the advisory's reproduction requires the integrator's authenticate_client to accept public clients.