CVE-2026-49265: 
Python vulnerability analysis and mitigation

CVE-2026-49265 is a timing side-channel vulnerability in the PKCE (RFC 7636) implementation of the Authorization Code Grant flow in the oauthlib Python library. The flaw exists in the code_challenge_method_plain and code_challenge_method_s256 functions within oauthlib/oauth2/rfc6749/grant_types/authorization_code.py, which use Python's standard == operator instead of a constant-time comparison function. It affects oauthlib versions >= 3.0.0 and < 4.0.0 (patched in 3.3.2 and 4.0.0). The vulnerability was published on September 28, 2026, and carries a CVSS v3.1 base score of 6.8 (Moderate) (GitHub Advisory, oauthlib Advisory).

The root cause is classified as CWE-208 (Observable Timing Discrepancy). Python's == operator uses short-circuit evaluation: it returns False immediately if string lengths differ, and otherwise compares characters left-to-right, stopping at the first mismatch. This means comparison time varies linearly with the length of the common prefix between the attacker-supplied code_verifier and the stored code_challenge, creating a measurable timing oracle. A proof-of-concept demonstrated a ~37ms delta over 10 million iterations (nanosecond-level per call), which is statistically exploitable under controlled, low-noise conditions. The fix, merged in PR #963, replaces == with hmac.compare_digest() in both code_challenge_method_plain and code_challenge_method_s256 (GitHub Advisory, Patch Commit).

Successful exploitation could allow an attacker who has intercepted an OAuth2 authorization code (e.g., via Custom URI Scheme Hijacking) to recover the code_verifier character by character through repeated timing measurements against the /token endpoint, ultimately obtaining an access token and achieving account takeover. The confidentiality and integrity impacts are rated High, as a recovered token grants unauthorized access to protected resources. Availability is not impacted. Practical exploitability is significantly limited by the single-use nature of authorization codes and real-world network jitter, making this primarily a defense-in-depth concern (GitHub Advisory, oauthlib Advisory).

No public exploit code or in-the-wild exploitation has been reported for CVE-2026-49265. The CVE status was listed as "Reserved" at time of publication, and no CISA KEV catalog entry exists. The attack complexity is rated High due to the requirement for prior interception of an authorization code, user interaction, and the need to overcome network timing noise. The EPSS score is not yet published. The vulnerability was reported by researcher "Rickidevs" and credited to Elvin Latifli (GitHub Advisory).

1. Prerequisite — Intercept Authorization Code: Position the attacker to intercept an OAuth2 authorization code, for example by registering a malicious app with a custom URI scheme that hijacks the redirect from a legitimate OAuth2 flow.
2. Identify Target Endpoint: Locate the /token endpoint of the OAuth2 authorization server using oauthlib as its backend (versions >= 3.0.0, < 3.3.2 or < 4.0.0).
3. Send Repeated Token Requests: Submit a high volume of token exchange requests to the /token endpoint, each with a candidate code_verifier that shares a progressively longer prefix with the target value (e.g., start with A + padding, then AA + padding, etc.).
4. Measure Response Timing: Record precise response times for each request. Requests where more characters match will take marginally longer due to the non-constant-time == comparison.
5. Recover Verifier Character by Character: Use statistical analysis of timing deltas to determine each correct character of the code_verifier sequentially, exploiting the ~nanosecond-level timing difference per matching character.
6. Exchange Code for Token: Once the full code_verifier is recovered, submit a valid token request to obtain an access token and achieve account takeover (GitHub Advisory, oauthlib Advisory).

• Network: Unusually high volume of repeated POST requests to the OAuth2 /token endpoint from a single IP or small IP range, each with slightly varying code_verifier values and the same code parameter.
• Logs: Authorization server logs showing many failed token exchange attempts for the same authorization code with different code_verifier values before a successful exchange; rapid sequential requests with near-identical parameters.
• Application Behavior: A single authorization code being submitted in token requests far more times than expected (authorization codes are single-use; multiple attempts indicate probing).

Upgrade oauthlib to version 3.3.2 or 4.0.0, both of which replace the vulnerable == operator with hmac.compare_digest() for constant-time comparison in code_challenge_method_plain and code_challenge_method_s256. No configuration-based workaround is available; patching is the only remediation. Downstream projects depending on oauthlib (e.g., databricks-sql-python) should also update their dependency constraints to allow oauthlib 3.3.2+ or 4.x (GitHub Advisory, Patch Commit, PR #963).

The fix was merged by oauthlib maintainer JonathanHuot on July 14, 2026, and included in the 4.0.0 release on September 27–28, 2026. The advisory notes that practical exploitability is limited due to the single-use nature of authorization codes and real-world network noise, framing the fix as a defense-in-depth measure. Downstream projects such as databricks-sql-python promptly opened issues to update their oauthlib dependency constraints in response to the advisory (PR #963, GitHub Advisory).