CVE-2026-28498: 
Python vulnerability analysis and mitigation

CVE-2026-28498 is a fail-open cryptographic verification vulnerability in the Authlib Python library affecting OpenID Connect (OIDC) ID Token validation. The flaw resides in the _verify_hash function (authlib/oidc/core/claims.py), which silently returns True when it encounters an unsupported or unknown cryptographic algorithm, effectively bypassing mandatory at_hash (Access Token Hash) and c_hash (Authorization Code Hash) integrity checks. All Authlib versions up to and including 1.6.8 are affected; the issue was disclosed on March 15, 2026, and patched in version 1.6.9. It carries a CVSS v3.1 base score of 7.5 (High) and a CVSS v4.0 base score of 8.2 (High) (Github Advisory, Red Hat Bugzilla).

The root cause is classified as CWE-354 (Improper Validation of Integrity Check Value) and CWE-573 (Improper Following of Specification by Caller). The vulnerable code in _verify_hash(signature, s, alg) calls create_half_hash(s, alg), which internally uses getattr(hashlib, hash_type, None) and returns None for any unrecognized algorithm. The original guard condition if not hash_value: return True incorrectly treats None (algorithm unsupported) the same as a falsy empty bytes object, causing the function to report successful verification without performing any cryptographic comparison. An attacker exploiting Hybrid or Implicit OIDC flows can forge a JWT with an arbitrary unsupported alg header value (e.g., "CUSTOM_ALG", "XX9999", "none") to bypass at_hash or c_hash binding checks entirely, enabling Token Substitution and Authorization Code Substitution attacks. This violates OpenID Connect Core 1.0 §§ 3.2.2.9 and 3.3.2.11, RFC 8725 § 3.1.1, and RFC 7515 § 5.2 (Github Advisory, Patch Commit).

Successful exploitation allows an unauthenticated network attacker to forge OIDC ID Tokens that pass hash-based integrity verification, enabling user impersonation and unauthorized access to resources protected by Authlib-based OIDC authentication. In Implicit Flow scenarios, an attacker can substitute a malicious access token for a legitimate one without detection; in Hybrid Flow scenarios, an attacker can perform Authorization Code Substitution, potentially hijacking authentication sessions. Confidentiality impact is limited (no direct data exfiltration from the library itself), but the integrity impact is high as the attacker can gain unauthorized access to downstream systems and resources that trust the OIDC authentication layer (Github Advisory).

A proof-of-concept script is publicly available in the GitHub Security Advisory, demonstrating the fail-open behavior by calling Authlib's vulnerable functions directly; however, this PoC only illustrates the bug locally and does not constitute a weaponized exploit targeting live deployments (Github Advisory). There is no confirmed evidence of in-the-wild exploitation, no known threat actor attribution, and the vulnerability is not listed in the CISA KEV catalog. The EPSS score is approximately 0.019–0.029%, indicating a low near-term exploitation probability. Exploitation requires the attacker to participate in an active OIDC flow (Attack Requirements: Present) and have the ability to craft or intercept JWT tokens, making opportunistic mass exploitation less likely than targeted attacks against specific OIDC-relying applications.

1. Identify target: Locate a web application using Authlib ≤ 1.6.8 for OIDC authentication in Implicit or Hybrid flow mode, where at_hash or c_hash claims are present in ID Tokens.
2. Initiate legitimate OIDC flow: Begin a normal authentication flow with the target Identity Provider (IdP) to obtain a legitimately signed ID Token and understand the token structure.
3. Craft forged JWT header: Modify the JWT header of the ID Token, replacing the legitimate alg value (e.g., RS256) with an arbitrary unsupported algorithm string such as "CUSTOM_ALG", "XX9999", or "none".
4. Substitute malicious token/code: Replace the access_token or authorization code bound to the ID Token with a malicious or mismatched value, while setting a fake at_hash or c_hash claim value (e.g., "FAAAAAAAAAAAAAAAAAAAA") that does not correspond to the substituted token.
5. Submit forged token: Send the crafted ID Token to the target application's OIDC callback or token validation endpoint.
6. Bypass verification: Authlib's _verify_hash receives None from create_half_hash (because the alg is unsupported), evaluates if not None as True, and returns True — silently accepting the forged token without raising InvalidClaimError.
7. Achieve authentication bypass: The application accepts the substituted access token or authorization code, granting the attacker unauthorized access as the impersonated user (Github Advisory).

• Network: OIDC callback requests containing JWT tokens with non-standard or unrecognized alg header values (e.g., CUSTOM_ALG, XX9999, none, RS, empty string) in the Authorization header or POST body.
• Logs: Application or OIDC middleware logs showing successful token validation for ID Tokens with unsupported algorithm identifiers without a corresponding InvalidClaimError; absence of hash verification errors despite mismatched at_hash/c_hash values.
• Application Behavior: Authentication successes for sessions where the alg field in the decoded JWT header does not match any standard algorithm (RS256, HS256, ES256, PS256, etc.); unexpected user sessions or access grants that cannot be correlated with legitimate IdP-issued tokens.
• File System / Dependencies: Presence of Authlib package version ≤ 1.6.8 in the Python environment (pip show authlib or pip freeze | grep authlib) (Github Advisory).

The primary remediation is to upgrade Authlib to version 1.6.9 or later, which changes the _verify_hash function to use if hash_value is None: return False instead of if not hash_value: return True, enforcing fail-closed behavior for unsupported algorithms (Patch Commit, Release v1.6.9). No configuration-based workaround exists at the library level, as the flaw is embedded in the core validation logic that all implementing developers rely upon. As a defense-in-depth measure, applications should validate that incoming JWT alg header values are restricted to an explicit allowlist of supported algorithms before passing tokens to Authlib for validation. IBM has also released an advisory for affected watsonx Orchestrate products that bundle Authlib (IBM Advisory).

The vulnerability received coverage from security news outlets, including SecurityOnline.info, which reported on it alongside related Authlib JWT forgery and padding oracle issues (SecurityOnline). The Hacker Wire shared information about the CVE on Mastodon, contributing to community awareness. OpenSUSE and Debian issued security announcements for their packaged versions of python-authlib, and Red Hat tracked the issue via Bugzilla with 37 CC'd team members, indicating broad vendor attention (Red Hat Bugzilla). The vulnerability was credited to researchers Pr00fOf3xpl0it and Jaynornj.