oauthlib CVE-2026-49265

Requires the target to use oauthlib's OAuth2 Authorization Code Grant with PKCE (RFC 7636) validation - the vulnerable code_challenge_method_plain / code_challenge_method_s256 comparison in authorization_code.py - on a vulnerable version (>=3.0.0, <4.0.0). Exploitation is heavily limited: the attacker must first independently obtain a valid authorization_code (e.g. via custom-URI-scheme hijacking, reflected in UI:R), must be able to issue and precisely time a very large volume of /token requests, and must complete character-by-character verifier recovery within the lifetime of a SINGLE-USE authorization code - which, combined with real-world network jitter dwarfing the nanosecond-per-call timing delta, makes practical exploitation marginal. Mitigated entirely by upgrading to oauthlib 4.0.0.

This is a genuine but low-real-world-risk defense-in-depth issue whose signals point consistently downward despite a mid-range CVSS. The vendor CVSS 3.1 vector (6.8, AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N) already encodes the key limiter as AC:H, and the C:H/I:H impact reflects the best-case downstream outcome (full account takeover) only IF the code_verifier is successfully recovered. No EPSS score, no CISA KEV listing, and no weaponized public exploit accompany this CVE - the 'Proof of Concept' in the advisory is a LOCAL Python microbenchmark (37ms delta over 10 MILLION iterations with network jitter deliberately removed), not a working remote exploit that recovers a verifier. The advisory author explicitly downgrades practical exploitability, noting that authorization codes are single-use (they expire long before a network-based char-by-char recovery could complete) and that real-world network noise swamps the nanosecond-per-call timing difference. Net: the C:H/I:H rating describes a theoretical worst case, while AC:H plus the single-use-code constraint make this closer to a code-hygiene fix than an urgent, actively-threatened flaw. Prioritize the routine upgrade to 4.0.0, but this is not a fire-drill.

An attacker who has already intercepted an authorization_code (e.g. via custom-URI-scheme hijacking on a mobile client) but lacks the PKCE code_verifier sends many timed requests to the /token endpoint, measuring server response time to infer, character by character, how much of their guessed verifier matches the stored challenge, ultimately reconstructing it to redeem the code for an access token. No public working exploit exists - the referenced PoC is only a local timing microbenchmark, and single-use code expiry plus network noise make end-to-end recovery largely theoretical.