Bug 2550336 (CVE-2026-49265)
| Summary: | CVE-2026-49265 oauthlib: oauthlib: Timing attack vulnerability in PKCE code_verifier/code_challenge comparison allows authorization code recovery | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | OSIDB Bzimport <bzimport> |
| Component: | vulnerability | Assignee: | Product Security DevOps Team <prodsec-dev> |
| Status: | NEW --- | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | unspecified | CC: | akhatavk, alinfoot, amctagga, anpicker, anthomas, aoconnor, aos-team-art-private, aprice, asdas, bbrownin, bniver, bparees, brasmith, cahl, cochase, dfreiber, dkeler, doconnor, dpaolell, dranck, drow, dschmidt, dtrifiro, dymurray, ebourniv, eglynn, ehelms, flucifre, gbenhaim, ggainey, gmeno, gparvin, groman, gtanzill, hasun, hoberger, ibolton, ikhan, jbalunas, jburrell, jbuscemi, jdelft, jdobes, jfula, jjoyce, jlanda, jmatthew, jmitchel, jmontleo, jowilson, jpasqual, jpretori, jsamir, jschluet, jupierce, juwatts, jwong, kaycoth, kbempah, kgaikwad, kshier, lgarciaa, lhh, ljawale, lpele, mbenjamin, mbiarnes, mburns, mdellweg, mgarciac, mhackett, mhulan, mrunge, msilmser, niyer, nmoumoul, nyancey, oezr, omaciel, ometelka, orabin, osousa, pakotvan, pcreech, pgaikwad, ppalepu, ppostler, prdhamdh, prwatson, ptisnovs, rbobbitt, rchan, rekumar, rhaigner, rhel-process-autobot, rjohnson, sarad, sbunciak, sghai, sidsharm, simaishi, slucidi, smallamp, solenoci, sostapov, sprizend, sseago, stcannon, sthirugn, suppawar, syedriko, thason, tmalecek, tsze, ttakamiy, twaugh, vereddy, vimartin, vkumar, vlaad, vvoronko, watson-tool-maintainers, weaton, xdharmai, yguenane |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | --- | |
| Doc Text: |
A flaw was found in oauthlib. A timing side-channel vulnerability in the Proof Key for Code Exchange (PKCE) validation process allows a remote attacker to recover secret verification codes. Because comparison operations do not execute in constant time, an attacker who has intercepted an authorization code can measure response latency differences across repeated requests to infer the expected verification code character-by-character. Successful exploitation allows the attacker to exchange the authorization code for an access token and impersonate the victim user.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | --- | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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.