CVE-2026-28498

What it actually does

Authlib’s OpenID Connect ID Token hash verifier (_verify_hash) fail-opens when the token’s algorithm identifier is unsupported or unknown. Mandatory at_hash (access-token hash) and c_hash (authorization-code hash) checks then return success instead of failing closed, so the library does not enforce the OIDC binding between an ID Token and the corresponding access token or authorization code. Token signature and other claim checks are out of scope of this flaw; the integrity property that is lost is specifically hash-based token binding.

Why it matters to the business

Python services that use Authlib as an OIDC/OAuth server or relying-party library may accept ID Tokens that are not cryptographically bound to the access token or authorization code, undermining login integrity and creating a path to unauthorized sessions or token misuse. The issue is not listed in CISA KEV, has no reported ransomware use, exploit maturity is none, and EPSS remains low (about 0.0026, up ~14% over 30 days), so mass opportunistic exploitation has not been observed. Residual risk is still material for any internet-facing identity flow that trusts Authlib’s hash checks, because a successful bypass is an authentication-integrity failure rather than a simple availability issue. Upgrade remaining Authlib deployments; the issue has been public for many months.

How an attack unfolds

An attacker targets an application that validates OIDC ID Tokens with Authlib before 1.6.9. They participate in a normal authorization-code or hybrid flow (or reuse a token set they already hold) and present an ID Token whose algorithm identifier is not implemented by the library’s hash logic. Instead of rejecting the unknown algorithm, Authlib treats at_hash and/or c_hash verification as passed, so a mismatched access token or authorization code can still be accepted. Impact is limited to bypassing those binding checks; the attacker still has to satisfy whatever signature, issuer, audience, nonce, and expiry checks the application performs. No named threat actors or in-the-wild campaigns are associated with this CVE, and there is no public exploit maturity, so known abuse is theoretical pending a weak surrounding validator or a complementary token-forgery condition.

How to fix it

Upgrade the authlib package to 1.6.9 or later everywhere it is a direct or transitive dependency (pip, Poetry, pipenv, conda, container base images, and lockfiles). Rebuild and redeploy all services that import Authlib for OIDC. As defense in depth, configure OIDC validation to allow-list only expected signing algorithms (for example RS256, ES256) and to reject unknown alg values; do not treat hash verification as optional. After upgrade, rotate any refresh tokens or long-lived grants issued while vulnerable builds were in production if your threat model assumes possible token-binding bypass. There is no complete configuration workaround on unpatched 1.6.8 and earlier.

How to confirm the fix worked

Inventory Python environments for authlib < 1.6.9 via lockfiles, SBOM, and runtime pip show/poetry show. Confirm production images and serverless layers actually shipped 1.6.9+. In a staging OIDC flow, verify that ID Tokens with an unrecognized algorithm cause at_hash/c_hash validation to fail closed (authentication denied), and that valid tokens with supported algorithms still succeed. Regression-test authorization-code and hybrid flows, including error paths. Re-scan dependencies after merge to catch transitive pins that did not move.

Typical attack path

1. Identify an application or API that validates OpenID Connect ID Tokens with Authlib earlier than 1.6.9
2. Engage the authorization-code, implicit, or hybrid login flow (or a token refresh/exchange that re-validates ID Token hashes)
3. Present an ID Token whose algorithm identifier is unsupported by Authlib’s hash verifier so at_hash and/or c_hash checks fail open
4. Complete the flow with an access token or authorization code that is not actually bound to that ID Token
5. Obtain an application session or API grant that should have been rejected for failed token-binding integrity

How to detect it

There are no public exploits, named actors, or KEV-listed ransomware campaigns for this issue, so confirmed compromise is unlikely but not provable from version alone. Hunt authentication and OIDC callback logs for ID Token validation that succeeded despite a non-allow-listed or unrecognized alg, especially where at_hash or c_hash would normally be required (authorization-code and hybrid flows). Compare those events to the Authlib version deployed at the time (package metadata, container SBOM, virtualenv). Look for sessions established with access tokens that do not correspond to the ID Token subject or c_hash/at_hash the identity provider issued. Useful sources: application auth logs, API gateway JWT/OIDC logs, IdP audit logs (authorization code redemption vs. client-presented tokens), and dependency inventories. Absence of unusual alg values does not prove the bug was unused, because a vulnerable library may not log the fail-open path.

What your security team should do

• Patch first: force authlib >= 1.6.9 in all application lockfiles and rebuild artifacts; treat remaining < 1.6.9 as an identity-integrity finding even though this CVE is not KEV
• Discover exposure: SBOM and repository search for authlib imports used in OIDC ID Token validation, including internal identity gateways and third-party Python services
• Harden validators: allow-list algorithms, fail closed on unknown alg, and keep issuer, audience, nonce, exp, and signature checks independent of hash verification
• Prioritize internet-facing login and token-exchange endpoints over internal-only tools when scheduling restarts
• After patching, review authentication logs around OIDC callbacks for anomalous algorithm identifiers; no mass exploitation is reported, so hunt is precautionary