Broken Keys: Critical Authlib Flaws Expose Millions to JWT Forgery and Padding Oracles

Security researchers exposed three critical vulnerabilities in Authlib, the widely used library for building OAuth and OpenID Connect servers. With over 86 million monthly downloads, the flaws in Authlib represent a massive risk to the global web infrastructure, potentially allowing attackers to bypass authentication, forge tokens, and decrypt sensitive data.

The first flaw, tracked as CVE-2026-28490 (CVSS 8.3), targets the library’s implementation of the RSA1_5 key management algorithm. While underlying cryptographic libraries typically include mitigations against “padding oracle” attacks, Authlib was found to “actively destroy” these protections.

By raising a specific ValueError immediately after decryption—before validating the data—the library creates a “clean, reliable Exception Oracle“.

“This oracle is active by default in every Authlib installation… The three most widely used Python web frameworks – Flask, Django, and FastAPI all expose distinguishable HTTP responses for these two exception classes,” the advisory explains.

Essentially, an attacker can use these different error responses to slowly “guess” the contents of encrypted data, bypassing intended security entirely.

The second vulnerability, CVE-2026-28498 (CVSS 8.2), uncovers a dangerous “fail-open” behavior in how Authlib validates OpenID Connect (OIDC) ID Tokens.

When the library encounters a cryptographic algorithm it doesn’t recognize in a token’s header, it doesn’t stop and throw an error. Instead, it “silently returns True,” effectively telling the application that the validation passed.

“This flaw allows an attacker to bypass mandatory integrity protections by supplying a forged ID Token with a deliberately unrecognized alg header parameter,” the advisory warns.

The most severe of the trio is CVE-2026-27962 (CVSS 9.1), a signature verification bypass that allows unauthenticated attackers to forge arbitrary JWT tokens.

The vulnerability triggers when an application passes key=None to a verification function—a common pattern in some JWKS lookup workflows. In this state, the library mistakenly trusts and uses a cryptographic key provided by the attacker within the token itself.

“An attacker can sign a token with their own private key, embed the matching public key in the header, and have the server accept the forged token as cryptographically valid—bypassing authentication and authorization entirely,” the advisory warns.

These vulnerabilities impact all versions of Authlib up to and including version 1.6.8. Because the library is a cornerstone of authentication for many enterprise applications, the “blast radius” is significant.

Critical Remediation Steps:

• Immediate Upgrade: Developers must update Authlib to version 1.6.9 or later to patch all three vulnerabilities.
• Audit Token Verification: Ensure that your application context—not the token itself—is always the source of the validation key.
• Disable RSA1_5: If your environment allows, migrate away from the older RSA1_5 algorithm in favor of more modern, AEAD-based key management.