CVE-2026-28490

What it actually does

Authlib’s default JWE stack registers RSA1_5 and strips the constant-time Bleichenbacher defenses provided by the underlying cryptography library, turning RSA PKCS#1 v1.5 key unwrapping into a remote padding oracle. A network attacker who can submit crafted JWE objects and observe distinguishable decryption failures or timing can recover the RSA-wrapped Content Encryption Key and decrypt the JWE plaintext (token claims, user attributes, or other confidential payload). Integrity impact is limited because content encryption still binds the payload, but confidentiality of any RSA1_5-protected JWE is lost. The condition is present in default algorithm registries prior to 1.6.9 and does not require an application to opt into RSA1_5.

Why it matters to the business

Any service that uses Authlib to decrypt OAuth, OpenID Connect, or other JWE tokens with RSA1_5 can have those tokens read by an unauthenticated remote party, exposing identities, session material, and other confidential claims. Authlib is a common Python OAuth/OIDC building block, so a single unpatched dependency can affect many applications. Exploitation is not listed in KEV, exploit maturity is none, and EPSS remains low (~0.0016, +12% over 30 days), so mass opportunistic abuse is not indicated; residual risk is still material for any internet-facing token endpoint that still accepts RSA1_5. The issue has been public for many months, so delayed patching is an avoidable compliance and incident-response liability.

How an attack unfolds

The attacker locates an Authlib-backed endpoint that unwraps JWE with RSA1_5 (Authorization servers, resource servers, or any API that decrypts encrypted JWTs). They send a large number of malformed RSA1_5-wrapped JWE objects, using differences in HTTP status, error text, or response timing as an oracle for PKCS#1 v1.5 padding validity. Adaptive queries recover the wrapped Content Encryption Key without the RSA private key. With the CEK, the attacker decrypts captured or intercepted JWE payloads and reads confidential claims. No credentials are required; attack complexity is high because thousands of queries and a distinguishable error channel are needed, which matches the published CVSS (AC:H, AT:P). No named threat actors or ransomware campaigns are associated with this CVE.

How to fix it

Upgrade the authlib package to 1.6.9 or later on every service that performs JWE decrypt or OIDC/OAuth token handling. After upgrade, remove RSA1_5 from allowed key-management algorithms and prefer RSA-OAEP or RSA-OAEP-256 (or ECDH-ES variants) for JWE key wrapping. Rotate any RSA keys that unwrapped RSA1_5 JWE in production, and treat previously issued RSA1_5 JWE as potentially disclosed. Pin the patched version in lockfiles (pip/poetry/uv) so transitive installs cannot pull a vulnerable Authlib. If an immediate upgrade is blocked, disable RSA1_5 at the application algorithm registry and reject incoming JWE with alg RSA1_5 at the edge.

How to confirm the fix worked

Confirm installed Authlib is 1.6.9 or newer in every runtime image and virtualenv (pip show authlib / poetry show authlib). Inspect application JOSE configuration and reject any registry that still lists RSA1_5 by default. In a staging decryptor, submit a JWE whose protected header uses alg RSA1_5 and verify it is refused rather than producing a padding- or decrypt-specific error. Regression-test legitimate RSA-OAEP (or ECDH-ES) JWE to ensure token issuance and consumption still succeed. Scan SBOMs and lockfiles for authlib<1.6.9 across services that implement OAuth/OIDC.

Typical attack path

1. Discover an Authlib service that decrypts JWE and still advertises or accepts RSA1_5 in the JOSE header
2. Capture or craft JWE objects targeting that RSA encryption key
3. Probe the decryptor with modified ciphertext and record distinguishable failures or timing
4. Iteratively recover PKCS#1 v1.5 padding validity until the Content Encryption Key is reconstructed
5. Decrypt the JWE plaintext and extract confidential claims or session material
6. Reuse recovered secrets against the same identity or API surface if they remain valid

How to detect it

Look for pre-patch Authlib decryptors (authlib < 1.6.9) that accepted JWE and for traffic patterns consistent with a padding-oracle campaign: high volumes of JWE/JWT decrypt failures from one client, many unique ciphertexts against the same key, and JOSE headers with alg=RSA1_5. Review API gateway, application, and web-server logs around token introspection, userinfo, or encrypted-JWT endpoints for clustered 4xx/5xx decrypt errors without matching legitimate client retries. Packet or access logs showing repeated POSTs of compact JWE (three or five base64url segments) to the same path are more useful than a single failure. There are no public in-the-wild exploits or named actors; absence of those IOCs does not prove non-exploitation. Correlate with deploy dates: activity before 1.6.9 is in-scope, activity after a confirmed patch and RSA1_5 rejection is likely noise.

• "alg":"RSA1_5"
• alg=RSA1_5
• RSA1_5
• authlib.jose.errors
• InvalidJWEData
• InvalidEncryptionAlgorithmError
• JWEError
• jose.jwe
• PKCS1_OAEP
• application/jose+json
• eyJhbGciOiJSU0ExXzUi

What your security team should do

• Patch Authlib to 1.6.9+ and redeploy all OAuth/OIDC and JWE-decrypting services as the first priority
• Disable and monitor for RSA1_5 in JOSE alg headers even after patching
• Rotate RSA wrapping keys and invalidate long-lived RSA1_5 JWE issued before the patch
• Add WAF/API rate limits and uniform decrypt error responses on token endpoints to raise the cost of oracle probing
• Inventory Python services for Authlib via SBOM/lockfile review; treat any remaining <1.6.9 as exposed
• Hunt historical logs for RSA1_5 and bursty JWE decrypt failures; no KEV-driven emergency window, but do not defer given 197 days since publication