A timing side-channel vulnerability exists in the PKCE (RFC 7636) implementation
of the Authorization Code Grant flow. The code_challenge_method_plain function
uses Python's standard == operator for string comparison instead of a
constant-time comparison function, potentially allowing timing-based attacks.
oauthlib/oauth2/rfc6749/grant_types/authorization_code.pycode_challenge_method_plain, code_challenge_method_s256Python's == operator uses short-circuit evaluation when comparing strings:
False immediately if lengths differThis means comparison time varies linearly with the length of the common prefix between the attacker-supplied verifier and the stored challenge, creating a measurable timing oracle.
Tested locally against oauthlib source (network jitter eliminated to isolate pure Python execution time):
| Input | Result | Time (10M iterations) |
|---|---|---|
Wrong first char (B + A*49) |
Fast reject | 0.34106s |
49 chars correct (A*49 + B) |
Deep compare | 0.37847s |
| Difference | 0.03741s |
The ~37ms delta over 10M iterations corresponds to nanosecond-level differences per call, which are statistically exploitable under controlled conditions.
authorization_code via Custom URI Scheme Hijackingcode_verifier/token endpoint measuring response timescode_verifier character by characterNote: Practical exploitability is limited due to the single-use nature of authorization codes and real-world network noise. However, the vulnerable pattern should be corrected as a defense-in-depth measure.
Replace == with hmac.compare_digest() for constant-time comparison:
cr: Elvin Latifli
{
"cwe_ids": [
"CWE-208"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-29T17:56:31Z",
"nvd_published_at": null,
"severity": "MODERATE"
}