CVE-2026-114616: Authlib Zero-Length HMAC Key JWT Signature Forgery

CVE-2026-114616 lets an attacker forge a validly-signed HS256/HS384/HS512 JWT or JWS token in applications using Authlib, because Authlib's OctKey.import_key() and HMAC code path accept a zero-length key as valid; NVD's own analysis scores it 9.1 critical because an application whose secret lookup can return an empty string or empty bytes — for example a misconfigured or absent per-tenant secret — will then accept tokens signed with a key any remote party can reproduce.

CVE-2026-114616 is an authentication-bypass vulnerability (CWE-287) in Authlib, a Python library used to build OAuth 2.0 and OpenID Connect authorization servers and clients. Authlib's symmetric (oct) key handling accepts an empty key — b'' or '' — as valid HMAC signing and verification material in OctKey.import_key() and the associated HS256/HS384/HS512 signing/verification path. Because HMAC with an empty key produces a deterministic digest that any party can compute without knowing any secret, an attacker who knows or can cause an application to verify a token against an empty secret can forge arbitrary token claims and have Authlib accept the token as authentically signed (GitHub Security Advisory GHSA-8m4g-j4wp-wgcg).

The advisory notes Authlib is the Python member of a cross-language family of empty-HMAC-key bugs, alongside already-assigned CVE-2026-44351 in the npm package fast-jwt and CVE-2026-45363 in the RubyGem ruby-jwt. It is explicitly distinct from three other recent Authlib JWT-verification advisories: CVE-2026-27962 / GHSA-wvwj-cvrp-7pv5 (JWS JWK header injection via key=None), CVE-2026-28802 / GHSA-7wc2-qxgw-g8gg (the alg: none blank-signature bypass), and GHSA-5357-c2jx-v7qh (algorithm confusion between asymmetric and symmetric keys) — none of those issues reject a zero-length oct key, so fixes for them did not close this gap (GHSA-8m4g-j4wp-wgcg).

NVD performed its own CNA analysis and assigned a Primary CVSS v3.1 base score of 9.1 (critical), vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N; GitHub's own CNA submission rates it lower, 7.4 (Secondary), vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N, reflecting a higher attack-complexity assessment (NVD).

The vulnerability affects Authlib versions prior to 1.9.1 and is fixed in 1.9.1, which rejects zero-length key material in the oct key and HMAC signing/verification path (NVD; GHSA-8m4g-j4wp-wgcg).

As of 2026-10-30, FIRST scores the probability of exploitation at 0.00299 (22.6th percentile) (FIRST EPSS). It is not listed in the CISA Known Exploited Vulnerabilities catalog (checked against catalog version 2026.10.30). The practical risk depends on whether a deployment's secret-lookup logic can ever return an empty value — for example, a per-client or per-tenant HMAC secret that was never provisioned, or a configuration bug that resolves to an empty string — so teams using Authlib for JWT/JWS verification should upgrade to 1.9.1 and audit secret-provisioning paths for the possibility of an empty secret reaching the verifier.

• Authlib's OctKey.import_key() and HMAC signing/verification path accept a zero-length (empty) key as valid, allowing deterministic HS256/HS384/HS512 signature forgery if an application's secret lookup can return an empty value. — GitHub Security Advisory
• NVD Primary CVSS v3.1 base score is 9.1 (critical), vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N, CWE-287; GitHub's own CNA submission scores it 7.4 (Secondary) with higher attack complexity. — NVD
• NVD CPE match data lists Authlib versions through 1.9.0 as vulnerable (confirmed present at v1.7.2 and on main HEAD by the reporter); fixed in version 1.9.1. — NVD
• EPSS score is 0.00299 (22.6th percentile) as of 2026-10-30; not listed in CISA KEV as of catalog version 2026.10.30. — FIRST EPSS