A timing side-channel exists in oauthlib's PKCE (RFC 7636) verification, used by
`AuthorizationCodeGrant` to validate the `code_verifier` presented at the token
endpoint against the `code_challenge` stored at authorization time
(`oauthlib/oauth2/rfc6749/grant_types/authorization_code.py`):

    def code_challenge_method_plain(verifier, challenge):
        return verifier == challenge

    def code_challenge_method_s256(verifier, challenge):
        return base64.urlsafe_b64encode(
            hashlib.sha256(verifier.encode()).digest()
        ).decode().rstrip('=') == challenge

Both comparisons use Python's `==` operator, which short-circuits on the first
mismatching byte. Response timing therefore leaks the length of the correct prefix
of an attacker-supplied verifier, giving a remote timing oracle that can in principle
be used to recover a valid `code_verifier` character-by-character via repeated
requests to the token endpoint.

Attack scenario:
1. Attacker intercepts a victim's `authorization_code` (e.g. via custom URI scheme
   hijacking on a public/native OAuth client), but does not know the `code_verifier`.
2. Attacker repeatedly submits token requests with guessed `code_verifier` values,
   measuring response latency to infer correct-prefix length at each position.
3. Having recovered a verifier that matches the stored challenge, the attacker
   exchanges the authorization code for an access token, impersonating the victim.

Practical exploitability is constrained: it requires high-precision timing
measurement over the network (noise needs to be largely eliminated), repeated
requests against the same still-valid authorization code, and a vulnerable
client/server deployment that doesn't invalidate the code after a failed exchange
attempt. These constraints are also called out by the reporting researcher as
limiting real-world exploitability, with the fix framed as defense-in-depth.

Source: GHSA-xpv3-w29h-x7cv
(https://github.com/oauthlib/oauthlib/security/advisories/GHSA-xpv3-w29h-x7cv),
published 2026-09-29 by the oauthlib maintainers, CWE-208, reported by GitHub user
Rickidevs.