Vulnerability-Lookup

PYSEC-2026-4356

Vulnerability from pysec - Published: 2026-10-22 22:18 - Updated: 2026-10-30 09:33

Details

Authlib is a Python library which builds OAuth and OpenID Connect servers. Prior to 1.9.1, Authlib's OctKey.import_key() and HMAC signing and verification path accept zero-length key material. If an application's secret lookup can return an empty string or empty bytes, a remote attacker can compute the deterministic HS256, HS384, or HS512 signature for arbitrary token claims and have Authlib treat the token as authentic. This issue is fixed in version 1.9.1.

Severity

9.1 (Critical)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

Impacted products

Name	purl
authlib	pkg:pypi/authlib

Aliases

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {},
      "package": {
        "ecosystem": "PyPI",
        "name": "authlib",
        "purl": "pkg:pypi/authlib"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.9.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "0.1",
        "0.10",
        "0.11",
        "0.12",
        "0.12.1",
        "0.13",
        "0.14",
        "0.14.1",
        "0.14.2",
        "0.14.3",
        "0.15",
        "0.15.1",
        "0.15.2",
        "0.15.3",
        "0.15.4",
        "0.15.5",
        "0.15.6",
        "0.1rc0",
        "0.2",
        "0.2.1",
        "0.3",
        "0.4",
        "0.4.1",
        "0.5",
        "0.5.1",
        "0.6",
        "0.7",
        "0.8",
        "0.9",
        "1.0.0",
        "1.0.0a1",
        "1.0.0a2",
        "1.0.0b1",
        "1.0.0b2",
        "1.0.0rc1",
        "1.0.1",
        "1.1.0",
        "1.2.0",
        "1.2.1",
        "1.3.0",
        "1.3.1",
        "1.3.2",
        "1.4.0",
        "1.4.1",
        "1.5.0",
        "1.5.1",
        "1.5.2",
        "1.6.0",
        "1.6.1",
        "1.6.10",
        "1.6.11",
        "1.6.12",
        "1.6.2",
        "1.6.3",
        "1.6.4",
        "1.6.5",
        "1.6.6",
        "1.6.7",
        "1.6.8",
        "1.6.9",
        "1.7.0",
        "1.7.1",
        "1.7.2",
        "1.8.0",
        "1.9.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2026-114616",
    "GHSA-8m4g-j4wp-wgcg"
  ],
  "details": "Authlib is a Python library which builds OAuth and OpenID Connect servers. Prior to 1.9.1, Authlib\u0027s OctKey.import_key() and HMAC signing and verification path accept zero-length key material. If an application\u0027s secret lookup can return an empty string or empty bytes, a remote attacker can compute the deterministic HS256, HS384, or HS512 signature for arbitrary token claims and have Authlib treat the token as authentic. This issue is fixed in version 1.9.1.",
  "id": "PYSEC-2026-4356",
  "modified": "2026-10-30T09:33:49.360662Z",
  "published": "2026-10-22T22:18:04.420Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://github.com/authlib/authlib/releases/tag/v1.9.1"
    },
    {
      "type": "FIX",
      "url": "https://github.com/authlib/authlib/commit/4ff30db442c70e29486e1982cb0ad37c037f5f4b"
    },
    {
      "type": "EVIDENCE",
      "url": "https://github.com/authlib/authlib/security/advisories/GHSA-8m4g-j4wp-wgcg"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8M4G-J4WP-WGCG

Vulnerability from github – Published: 2026-10-27 16:09 – Updated: 2026-10-27 16:09

Summary

Authlib accepts an empty HMAC key, allowing JWS/JWT signature forgery (HS256/HS384/HS512)

Details

Reporter: Cavan Loughran, Celvex Group Inc.

Summary

Authlib's symmetric (oct) key handling accepts an empty key (empty bytes b'' / empty string '') as a valid HMAC signing and verification key. An empty HMAC key produces a deterministic digest that any party can reproduce, so an attacker who knows (or can cause) the application to verify a token with an empty key can forge arbitrary tokens that pass HS256/HS384/HS512 signature verification. This is the Authlib member of the cross-language empty-HMAC-key family already assigned CVE-2026-44351 (fast-jwt, npm) and CVE-2026-45363 (ruby-jwt, RubyGems).

This is DISTINCT from Authlib's existing recent JWT-verification advisories. It is not closed by CVE-2026-27962 / GHSA-wvwj-cvrp-7pv5 (JWS JWK header injection, the key=None case), nor by CVE-2026-28802 / GHSA-7wc2-qxgw-g8gg (alg:none blank-signature bypass), nor by GHSA-5357-c2jx-v7qh (algorithm confusion with asymmetric public keys). Those address header-driven key injection, the none algorithm, and asymmetric-vs-symmetric confusion respectively; none of them rejects a zero-length oct key.

Affected versions

Authlib <= 1.7.2 (latest release 1.7.2, 2026-05-06). Confirmed present at the v1.7.2 release tag and on the current main HEAD. The affected code is in authlib/jose/rfc7518/oct_key.py and authlib/jose/rfc7518/jws_algs.py.

Root cause (exact code location, release tag v1.7.2)

authlib/jose/rfc7518/oct_key.py, class OctKey:
validate_raw_key is a type-only check: return isinstance(key, bytes). An empty bytes object passes.
import_key rejects only keys whose material starts with known unsafe prefixes (if raw_key.startswith(POSSIBLE_UNSAFE_KEYS): raise ValueError(...), i.e. PEM/SSH prefixes). Empty bytes do not match any unsafe prefix, so b'' is accepted.
get_op_key loads the raw key without validating its length.
No check anywhere rejects a zero-length key, so an empty key b'' passes every gate.
authlib/jose/rfc7518/jws_algs.py, class HMACAlgorithm:
prepare_key: return OctKey.import_key(raw_data).
sign / verify call key.get_op_key(...) then hmac.new(op_key, msg, self.hash_alg) / hmac.compare_digest(...). With an empty op key this becomes hmac.new(b'', ...): a deterministic, publicly reproducible digest. There is no empty-key or minimum-length check.

Why this is a real signature bypass

An empty HMAC key makes the signature a public, deterministic function of the header and payload, so anyone can compute a valid signature and forge tokens. The realistic trigger matches the sibling CVEs: the deploying application sources the verification key from a place that can be empty at runtime, for example os.environ.get('JWT_SECRET', ''), a database/config column whose default is '', or a key-resolver that returns '' on a miss. Authlib is widely used to BUILD token verifiers (OAuth 2.0 resource servers, OIDC relying parties), and Authlib's own recent advisory history shows the JWS/JWT verify path is the live attack surface, so a key-resolution path that can yield '' is a realistic exposure.

Reproduction (prose, no weaponized exploit)

In an application that uses Authlib to verify JWS/JWT, arrange for the verification key to be an empty value (e.g. an unset environment variable defaulted to '').
An attacker constructs a token with header {alg: HS256} and an arbitrary payload, and computes the HS256 signature using an empty key (a value any party can reproduce because the key is empty).
Authlib's HMAC verification accepts the token as validly signed, because OctKey.import_key did not reject the empty key and hmac.compare_digest matches the attacker-computable digest. The forged token is treated as authentic.

No live system was probed; the above describes the class. The vulnerable code path and the absent guard are confirmed by direct reading of the public source at the v1.7.2 tag and on current main.

Proof the fix is known-good (no novelty risk)

The same maintainer's newer JOSE library, joserfc, ALREADY rejects empty oct key material outright. In src/joserfc/_rfc7518/oct_key.py, import_key raises a ValueError on empty oct material, with an explicit note that an empty oct key produces a deterministic HMAC digest that any party can reproduce, allowing trivial signature forgery in JWS HS256/HS384/HS512 verification. (joserfc additionally warns on keys below 112 bits.) The same guard is simply absent from the older, far more widely deployed Authlib rfc7518 package. The flagship Python JOSE libraries also guard: PyJWT raises InvalidKeyError('HMAC key must not be empty.') for zero-length keys, and jwcrypto enforces an RFC 7518 minimum key length.

Impact

Token forgery / authentication bypass in OAuth 2.0 resource servers and OIDC relying parties built on Authlib whenever the HMAC verification key can be empty at runtime. An attacker can mint tokens with arbitrary claims (for example elevated scopes or another user's subject) that pass signature verification.

Suggested remediation

Reject empty oct key material in OctKey.import_key (and/or validate_raw_key), exactly as the maintainer's joserfc library already does, before the key can reach hmac.new in HMACAlgorithm.sign / verify. Consider also adopting joserfc's sub-112-bit minimum-length warning/rejection for HMAC keys.

Disclosure

Reporter: Cavan Loughran, Celvex Group Inc.

Severity

7.4 (High)


                  
                    CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "Authlib"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.9.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-114616"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1391",
      "CWE-287",
      "CWE-326"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-27T16:09:22Z",
    "nvd_published_at": "2026-10-22T22:18:04Z",
    "severity": "HIGH"
  },
  "details": "Reporter: Cavan Loughran, Celvex Group Inc.\n\nSummary\n\nAuthlib\u0027s symmetric (oct) key handling accepts an empty key (empty bytes b\u0027\u0027 / empty string \u0027\u0027) as a valid HMAC signing and verification key. An empty HMAC key produces a deterministic digest that any party can reproduce, so an attacker who knows (or can cause) the application to verify a token with an empty key can forge arbitrary tokens that pass HS256/HS384/HS512 signature verification. This is the Authlib member of the cross-language empty-HMAC-key family already assigned CVE-2026-44351 (fast-jwt, npm) and CVE-2026-45363 (ruby-jwt, RubyGems).\n\nThis is DISTINCT from Authlib\u0027s existing recent JWT-verification advisories. It is not closed by CVE-2026-27962 / GHSA-wvwj-cvrp-7pv5 (JWS JWK header injection, the key=None case), nor by CVE-2026-28802 / GHSA-7wc2-qxgw-g8gg (alg:none blank-signature bypass), nor by GHSA-5357-c2jx-v7qh (algorithm confusion with asymmetric public keys). Those address header-driven key injection, the none algorithm, and asymmetric-vs-symmetric confusion respectively; none of them rejects a zero-length oct key.\n\nAffected versions\n\nAuthlib \u003c= 1.7.2 (latest release 1.7.2, 2026-05-06). Confirmed present at the v1.7.2 release tag and on the current main HEAD. The affected code is in authlib/jose/rfc7518/oct_key.py and authlib/jose/rfc7518/jws_algs.py.\n\nRoot cause (exact code location, release tag v1.7.2)\n\n- authlib/jose/rfc7518/oct_key.py, class OctKey:\n  - validate_raw_key is a type-only check: `return isinstance(key, bytes)`. An empty bytes object passes.\n  - import_key rejects only keys whose material starts with known unsafe prefixes (`if raw_key.startswith(POSSIBLE_UNSAFE_KEYS): raise ValueError(...)`, i.e. PEM/SSH prefixes). Empty bytes do not match any unsafe prefix, so b\u0027\u0027 is accepted.\n  - get_op_key loads the raw key without validating its length.\n  - No check anywhere rejects a zero-length key, so an empty key b\u0027\u0027 passes every gate.\n- authlib/jose/rfc7518/jws_algs.py, class HMACAlgorithm:\n  - prepare_key: `return OctKey.import_key(raw_data)`.\n  - sign / verify call key.get_op_key(...) then `hmac.new(op_key, msg, self.hash_alg)` / `hmac.compare_digest(...)`. With an empty op key this becomes hmac.new(b\u0027\u0027, ...): a deterministic, publicly reproducible digest. There is no empty-key or minimum-length check.\n\nWhy this is a real signature bypass\n\nAn empty HMAC key makes the signature a public, deterministic function of the header and payload, so anyone can compute a valid signature and forge tokens. The realistic trigger matches the sibling CVEs: the deploying application sources the verification key from a place that can be empty at runtime, for example os.environ.get(\u0027JWT_SECRET\u0027, \u0027\u0027), a database/config column whose default is \u0027\u0027, or a key-resolver that returns \u0027\u0027 on a miss. Authlib is widely used to BUILD token verifiers (OAuth 2.0 resource servers, OIDC relying parties), and Authlib\u0027s own recent advisory history shows the JWS/JWT verify path is the live attack surface, so a key-resolution path that can yield \u0027\u0027 is a realistic exposure.\n\nReproduction (prose, no weaponized exploit)\n\n1. In an application that uses Authlib to verify JWS/JWT, arrange for the verification key to be an empty value (e.g. an unset environment variable defaulted to \u0027\u0027).\n2. An attacker constructs a token with header {alg: HS256} and an arbitrary payload, and computes the HS256 signature using an empty key (a value any party can reproduce because the key is empty).\n3. Authlib\u0027s HMAC verification accepts the token as validly signed, because OctKey.import_key did not reject the empty key and hmac.compare_digest matches the attacker-computable digest. The forged token is treated as authentic.\n\nNo live system was probed; the above describes the class. The vulnerable code path and the absent guard are confirmed by direct reading of the public source at the v1.7.2 tag and on current main.\n\nProof the fix is known-good (no novelty risk)\n\nThe same maintainer\u0027s newer JOSE library, joserfc, ALREADY rejects empty oct key material outright. In src/joserfc/_rfc7518/oct_key.py, import_key raises a ValueError on empty oct material, with an explicit note that an empty oct key produces a deterministic HMAC digest that any party can reproduce, allowing trivial signature forgery in JWS HS256/HS384/HS512 verification. (joserfc additionally warns on keys below 112 bits.) The same guard is simply absent from the older, far more widely deployed Authlib rfc7518 package. The flagship Python JOSE libraries also guard: PyJWT raises InvalidKeyError(\u0027HMAC key must not be empty.\u0027) for zero-length keys, and jwcrypto enforces an RFC 7518 minimum key length.\n\nImpact\n\nToken forgery / authentication bypass in OAuth 2.0 resource servers and OIDC relying parties built on Authlib whenever the HMAC verification key can be empty at runtime. An attacker can mint tokens with arbitrary claims (for example elevated scopes or another user\u0027s subject) that pass signature verification.\n\n\nSuggested remediation\n\nReject empty oct key material in OctKey.import_key (and/or validate_raw_key), exactly as the maintainer\u0027s joserfc library already does, before the key can reach hmac.new in HMACAlgorithm.sign / verify. Consider also adopting joserfc\u0027s sub-112-bit minimum-length warning/rejection for HMAC keys.\n\nDisclosure\n\nReporter: Cavan Loughran, Celvex Group Inc.",
  "id": "GHSA-8m4g-j4wp-wgcg",
  "modified": "2026-10-27T16:09:22Z",
  "published": "2026-10-27T16:09:22Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/security/advisories/GHSA-8m4g-j4wp-wgcg"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-114616"
    },
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/commit/4ff30db442c70e29486e1982cb0ad37c037f5f4b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/authlib/authlib"
    },
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/releases/tag/v1.9.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Authlib accepts an empty HMAC key, allowing JWS/JWT signature forgery (HS256/HS384/HS512)"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

Order JSON

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted