CVE-2026-28802 is a critical (CVSS 9.8) signature verification flaw in Authlib versions 1.6.5 and 1.6.6. A JWT with alg set to none and an empty signature passed verification when it should have failed. The fix is Authlib 1.6.7, so upgrade and test token validation.
What's affected
The GitHub advisory lists the PyPI package authlib from 1.6.5 up to and including 1.6.6 as affected, and 1.6.7 as the first patched version. The NVD text says the behavior appeared from 1.6.5 up to before 1.6.7.
The advisory says the reporter noticed it after upgrading from 1.5.2, and it points to a specific earlier commit as the likely cause.
How to check if you're exposed
Check the version:
pip show authlib
In a lockfile, search for authlib. Versions 1.6.5 and 1.6.6 need the update. Also find the places in your code that decode or verify JWTs with Authlib, since those are the paths that depend on it.
What to do now
- Upgrade
authlibto 1.6.7 or later and refresh your lockfile. - Add a regression test that submits a token with alg none and an empty signature and asserts that it is rejected.
- Make verification code name the algorithms it accepts, so an unexpected value cannot be selected by the token.
- Review logs for accepted tokens that carry unusual headers if you ran an affected version.
- Rebuild and redeploy every service that bundles the library.
Why it matters
The record lists CWE-347, improper verification of a cryptographic signature. The JWT header tells a verifier which algorithm was used, and the value none means unsigned. A library must never let an incoming token pick that for a protected call, since anyone can create an unsigned token with any claims.
That is why the impact is so high. An attacker can mint a token that says whatever they like, for example a user with a role that opens doors, and a vulnerable verifier accepts it. The advisory's own example forges an administrator style claim, and it did not need a key.
The notable detail is that this was a regression. A behavior that older versions handled correctly broke in 1.6.x with no change to application code, which is a good reason to keep negative tests for authentication paths in your suite. The record does not mark the CVE as exploited in the wild.
Two Red Hat errata are listed in the record, so distribution packages may carry their own fixed builds.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Do I need to change my code after upgrading?
Not for the fix itself. It is still wise to pin the accepted algorithms in your verification code and add a test for unsigned tokens.
Sources
Last reviewed: 19 October 2026.
