CVE-2026-114615: Authlib incomplete algorithm-confusion fix permits HMAC forgery with prefixed public keys

OctKey.import_key() carries the only guard that stops an asymmetric public key from being used as an HMAC secret in authlib.jose. That guard is raw_key.startswith(POSSIBLE_UNSAFE_KEYS) — anchored at byte 0 — while the loader that consumes the identical bytes on the asymmetric path (cryptography.hazmat.primitives.serialization.load_pem_public_key / load_pem_x509_certificate) skips anything before the -----BEGIN line. A PEM public key or X.509 certificate carrying one leading byte — a newline, a space, four spaces of indentation, a UTF-8 BOM, or a comment line — is therefore not recognised, falls through, and becomes the HMAC secret. An attacker holding only the issuer’s public key then mints an HS256 token with arbitrary claims that jwt.decode() accepts as authentic.

This is an incomplete fix of CVE-2024-37568 / GHSA-5357-c2jx-v7qh. That advisory’s fix is exactly this guard (git log -S 'POSSIBLE_UNSAFE_KEYS' -- authlib/jose/rfc7518/oct_key.py returns a single commit, 3bea812 “fix: prevent OctKey to import ssh/rsa/pem keys”, referencing issue #654), and the original attack works again unchanged whenever the stored PEM does not start at offset 0.

Reproduced end-to-end on 1.8.0, the newest release (published 2026-08-30), and on origin/main (c529a61), with cryptography 50.0.2.