CVE-2026-28490: 
Python vulnerability analysis and mitigation

CVE-2026-28490 is a cryptographic padding oracle vulnerability in the Authlib Python library affecting its JSON Web Encryption (JWE) RSA1_5 key management algorithm implementation. All versions of Authlib up to and including 1.6.8 are affected; the issue was disclosed on March 15, 2026, and patched in version 1.6.9 released the same day. The vulnerability exists because Authlib registers RSA1_5 in its default algorithm registry without requiring explicit opt-in and actively destroys the constant-time Bleichenbacher mitigation provided by the underlying cryptography library. It carries a CVSS v3.1 base score of 6.5 (Medium) and a CVSS v4.0 base score of 8.3 (High) (Github Advisory, Feedly).

The root cause (CWE-203: Observable Discrepancy; CWE-327: Use of a Broken or Risky Cryptographic Algorithm) lies in authlib/jose/rfc7518/jwe_algs.py within the RSAAlgorithm.unwrap() method. When the underlying cryptography library encounters invalid PKCS#1 v1.5 padding, it returns a randomized byte string (per RFC 3218 §2.3.2) rather than raising an exception — the correct Bleichenbacher mitigation. Authlib immediately performs a CEK length check on this random output (if len(cek) * 8 != enc_alg.CEK_SIZE: raise ValueError('Invalid "cek" length')), which fires before AES-GCM tag validation and creates two distinguishable execution paths: invalid padding yields ValueError while valid padding with a wrong MAC yields InvalidTag. This exception oracle is active by default in every Authlib installation and is exploitable out-of-the-box with Flask, Django, and FastAPI in their default configurations, as each framework exposes distinguishable HTTP responses for the two exception types (Github Advisory).

An unauthenticated network attacker can exploit the exception oracle to mount a Bleichenbacher-style attack, submitting thousands of crafted JWE tokens and observing distinguishable server responses to geometrically narrow PKCS#1 v1.5 plaintext boundaries until the Content Encryption Key (CEK) is fully recovered. With the CEK recovered, the attacker can decrypt any intercepted JWE payload without possessing the RSA private key and forge new valid JWE tokens, enabling authentication bypass and sensitive data exposure. The confidentiality impact is rated High, with a Low integrity impact (token forgery), and no availability impact (Github Advisory, Feedly).

A proof-of-concept script (poc_bleichenbacher.py) is publicly available in the GitHub security advisory, demonstrating the exception oracle by creating RSA keys, crafting JWE tokens, and observing distinguishable exceptions (ValueError vs. InvalidTag) against the vulnerable library (Github Advisory). No in-the-wild exploitation has been observed as of the time of reporting. The EPSS score is approximately 0.015% (very low), and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution is available. The attack requires no authentication and no special server configuration, but does require high attack complexity (many requests) and the presence of an observable response difference (Feedly).

1. Reconnaissance: Identify Authlib-powered endpoints that accept JWE tokens (e.g., OIDC token endpoints, API gateways). Confirm the server uses Authlib ≤ 1.6.8 via version disclosure, error messages, or dependency scanning.
2. Obtain RSA public key: Retrieve the server's RSA public key from the standard JWKS endpoint (e.g., GET /.well-known/jwks.json), which is standard in OIDC deployments.
3. Craft malformed JWE tokens: Construct JWE compact serialization tokens with {"alg":"RSA1_5","enc":"A128GCM"} in the header. For the encrypted key (ek) component, use random bytes (invalid PKCS#1 v1.5 padding) to probe the oracle.
4. Submit oracle queries: Send crafted JWE tokens to the target decryption endpoint and observe the HTTP response. Invalid padding triggers ValueError: Invalid "cek" length (distinguishable response, e.g., different body length or status code); valid padding with wrong MAC triggers InvalidTag (different response).
5. Execute Bleichenbacher's algorithm: Iteratively manipulate the ek component per Bleichenbacher's adaptive chosen-ciphertext attack, using the oracle responses to geometrically narrow the PKCS#1 v1.5 plaintext space across thousands of requests.
6. Recover CEK: After sufficient oracle queries, fully recover the Content Encryption Key (CEK) without the RSA private key.
7. Decrypt or forge tokens: Use the recovered CEK to decrypt any intercepted JWE payload or forge new valid JWE tokens, achieving authentication bypass or sensitive data access (Github Advisory).

• Network: High volume of HTTP requests to JWE token decryption endpoints (e.g., token introspection, OIDC endpoints) from a single or rotating source IP, particularly with varied ek (encrypted key) components in JWE compact serialization format (header.ek.iv.ciphertext.tag).
• Network: Requests containing JWE tokens with "alg":"RSA1_5" in the decoded header, especially if RSA1_5 is not an expected algorithm for the deployment.
• Logs: Repeated HTTP 500 responses from JWE decryption endpoints, alternating between responses with body content (e.g., Invalid "cek" length message) and empty-body 500s — indicative of oracle probing.
• Logs: Application logs showing alternating ValueError: Invalid "cek" length and InvalidTag exceptions from authlib/jose/rfc7518/jwe_algs.py at high frequency.
• Logs: Error monitoring tools (Sentry, Datadog) reporting bursts of ValueError and cryptography.exceptions.InvalidTag exceptions from the same endpoint within a short time window.

The primary remediation is to upgrade Authlib to version 1.6.9 or later, which removes RSA1_5 from the default JWE algorithm registry (marking it as deprecated=True) and generates a random CEK fallback when the CEK length does not match, eliminating the exception oracle (Authlib Release, Patch Commit). As an immediate workaround for those unable to upgrade, explicitly configure JsonWebEncryption() with an algorithm allowlist that excludes RSA1_5, and implement application-level exception normalization so that all JWE decryption failures return an identical HTTP response regardless of exception type. IBM has also released patches for affected products including IBM Observability with Instana (OnPrem), IBM watsonx Code Assistant On Prem, and IBM watsonx Orchestrate with watsonx Assistant Cartridge (IBM Advisory).

The vulnerability was covered by SecurityOnline.info under the headline "Broken Keys: Critical Authlib Flaws — JWT Forgery, Padding Oracles" shortly after disclosure (SecurityOnline). Red Hat tracked the issue via Bugzilla (Bug 2448162) and classified it as medium severity, with 37 users CC'd on the report (Red Hat Bugzilla). OpenSUSE and Debian issued security announcements for their packaged versions of python-authlib, and the issue was picked up by Linux security news aggregators. No significant controversy or researcher disagreement was noted; the advisory's detailed technical write-up and attached PoC were well-received as a thorough disclosure.