https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 31 Oct 2026 02:46:19 +0000 https://db.gcve.eu/vuln/cve-2026-114615 <p><strong>Affected:</strong> authlib</p> <p>Authlib is a Python library which builds OAuth and OpenID Connect servers. From 1.3.1 until 1.9.0, OctKey.import_key() checks asymmetric-key markers only at byte zero while Authlib&#39;s PEM loaders accept leading whitespace, comments, or a byte-order mark. In deployments that use the documented mixed algorithm registry and already configure verification with PEM or certificate bytes containing such a prefix, an unauthenticated attacker who knows those same public-key bytes can use them as an HMAC secret and forge HS256 tokens with arbitrary identity or authorization claims. This is a bypass of the remediation for CVE-2024-37568. The module-level jwt object reaches OctKey.import_key() in authlib/jose/rfc7518/oct_key.py, where POSSIBLE_UNSAFE_KEYS fails to identify prefixed asymmetric key material. This issue is fixed in version 1.9.0.</p> <p><strong>Affected:</strong> authlib</p> <p>Authlib is a Python library which builds OAuth and OpenID Connect servers. From 1.3.1 until 1.9.0, OctKey.import_key() checks asymmetric-key markers only at byte zero while Authlib&#39;s PEM loaders accept leading whitespace, comments, or a byte-order mark. In deployments that use the documented mixed algorithm registry and already configure verification with PEM or certificate bytes containing such a prefix, an unauthenticated attacker who knows those same public-key bytes can use them as an HMAC secret and forge HS256 tokens with arbitrary identity or authorization claims. This is a bypass of the remediation for CVE-2024-37568. The module-level jwt object reaches OctKey.import_key() in authlib/jose/rfc7518/oct_key.py, where POSSIBLE_UNSAFE_KEYS fails to identify prefixed asymmetric key material. This issue is fixed in version 1.9.0.</p> https://db.gcve.eu/vuln/cve-2026-114615 https://db.gcve.eu/vuln/ghsa-7vr2-2fgp-9w7p <p><strong>Affected:</strong> PyPI: authlib</p> <p>## Summary</p> <p>`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&#39;s public key then mints an `HS256` token with arbitrary claims that `jwt.decode()` accepts as authentic.</p> <p>This is an incomplete fix of **CVE-2024-37568 / GHSA-5357-c2jx-v7qh**. That advisory&#39;s fix is exactly this guard (`git log -S &#39;POSSIBLE_UNSAFE_KEYS&#39; -- authlib/jose/rfc7518/oct_key.py` returns a single commit, `3bea812` &#34;fix: prevent OctKey to import ssh/rsa/pem keys&#34;, referencing issue #654), and the original attack works again unchanged whenever the stored PEM does not start at offset 0.</p> <p>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.</p> <p>## Preconditions</p> <p>Both are deployment properties; neither is attacker-controlled at request time, and the attacker needs no secret and no user interactio…</p> <p><strong>Affected:</strong> PyPI: authlib</p> <p>## Summary</p> <p>`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&#39;s public key then mints an `HS256` token with arbitrary claims that `jwt.decode()` accepts as authentic.</p> <p>This is an incomplete fix of **CVE-2024-37568 / GHSA-5357-c2jx-v7qh**. That advisory&#39;s fix is exactly this guard (`git log -S &#39;POSSIBLE_UNSAFE_KEYS&#39; -- authlib/jose/rfc7518/oct_key.py` returns a single commit, `3bea812` &#34;fix: prevent OctKey to import ssh/rsa/pem keys&#34;, referencing issue #654), and the original attack works again unchanged whenever the stored PEM does not start at offset 0.</p> <p>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.</p> <p>## Preconditions</p> <p>Both are deployment properties; neither is attacker-controlled at request time, and the attacker needs no secret and no user interactio…</p> https://db.gcve.eu/vuln/ghsa-7vr2-2fgp-9w7p