Vulnerability-Lookup

URL	Tags
https://github.com/authlib/authlib/security/advis…	x_refsource_CONFIRM
https://github.com/authlib/authlib/commit/4ff30db…	x_refsource_MISC
https://github.com/authlib/authlib/releases/tag/v1.9.1	x_refsource_MISC

Vendor	Product	Version	CPE status
authlib	authlib	Affected: < 1.9.1	guessed

BREW-FASTMCP-CVE-2026-114616 (GHSA-8M4G-J4WP-WGCG)

Vulnerability from osv_homebrew – Published: 2026-10-29 22:09 – Updated: 2026-10-31 10:19 – Source website

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

References

URL

Type

	https://github.com/authlib/authlib/security/advis…	WEB
	https://nvd.nist.gov/vuln/detail/CVE-2026-114616	ADVISORY
	https://github.com/authlib/authlib/commit/4ff30db…	WEB
	https://github.com/authlib/authlib	PACKAGE
	https://github.com/authlib/authlib/releases/tag/v1.9.1	WEB

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": "bump",
        "range_state": "fixed",
        "resource": "authlib",
        "resource_purl": "pkg:pypi/authlib@1.9.1",
        "upstream_fixed_in": "1.9.1"
      },
      "package": {
        "ecosystem": "Homebrew",
        "name": "fastmcp",
        "purl": "pkg:brew/fastmcp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.12.3"
            },
            {
              "fixed": "4.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "confidence": "high",
    "source": "matched",
    "strategy": "registry",
    "upstream_evidence": [
      {
        "ecosystem": "PyPI",
        "key": "pkg:pypi/authlib@1.9.1",
        "name": "authlib",
        "resource": "authlib",
        "strategy": "registry",
        "subject_version": "1.9.1"
      }
    ]
  },
  "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": "BREW-fastmcp-CVE-2026-114616",
  "modified": "2026-10-31T10:19:08Z",
  "published": "2026-10-29T22:09:40Z",
  "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.7.3",
  "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)",
  "upstream": [
    "GHSA-8m4g-j4wp-wgcg",
    "CVE-2026-114616",
    "PYSEC-2026-4356"
  ]
}

BREW-KASKADE-CVE-2026-114616 (GHSA-8M4G-J4WP-WGCG)

Vulnerability from osv_homebrew – Published: 2026-10-29 22:17 – Updated: 2026-10-31 10:32 – Source website

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

References

URL

Type

	https://github.com/authlib/authlib/security/advis…	WEB
	https://nvd.nist.gov/vuln/detail/CVE-2026-114616	ADVISORY
	https://github.com/authlib/authlib/commit/4ff30db…	WEB
	https://github.com/authlib/authlib	PACKAGE
	https://github.com/authlib/authlib/releases/tag/v1.9.1	WEB

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": null,
        "range_state": "affected",
        "resource": "authlib",
        "resource_purl": "pkg:pypi/authlib@1.7.2",
        "upstream_fixed_in": "1.9.1"
      },
      "package": {
        "ecosystem": "Homebrew",
        "name": "kaskade",
        "purl": "pkg:brew/kaskade"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "confidence": "high",
    "source": "matched",
    "strategy": "registry",
    "upstream_evidence": [
      {
        "ecosystem": "PyPI",
        "key": "pkg:pypi/authlib@1.7.2",
        "name": "authlib",
        "resource": "authlib",
        "strategy": "registry",
        "subject_version": "1.7.2"
      }
    ]
  },
  "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": "BREW-kaskade-CVE-2026-114616",
  "modified": "2026-10-31T10:32:38Z",
  "published": "2026-10-29T22:17: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.7.3",
  "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)",
  "upstream": [
    "GHSA-8m4g-j4wp-wgcg",
    "CVE-2026-114616",
    "PYSEC-2026-4356"
  ]
}

BREW-KIMI-CLI-CVE-2026-114616 (GHSA-8M4G-J4WP-WGCG)

Vulnerability from osv_homebrew – Published: 2026-10-29 23:30 – Updated: 2026-10-30 10:26 – Source website

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

References

URL

Type

	https://github.com/authlib/authlib/security/advis…	WEB
	https://nvd.nist.gov/vuln/detail/CVE-2026-114616	ADVISORY
	https://github.com/authlib/authlib/commit/4ff30db…	WEB
	https://github.com/authlib/authlib	PACKAGE
	https://github.com/authlib/authlib/releases/tag/v1.9.1	WEB

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": null,
        "range_state": "affected",
        "resource": "authlib",
        "resource_purl": "pkg:pypi/authlib@1.8.0",
        "upstream_fixed_in": "1.9.1"
      },
      "package": {
        "ecosystem": "Homebrew",
        "name": "kimi-cli",
        "purl": "pkg:brew/kimi-cli"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.40"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "confidence": "high",
    "source": "matched",
    "strategy": "registry",
    "upstream_evidence": [
      {
        "ecosystem": "PyPI",
        "key": "pkg:pypi/authlib@1.8.0",
        "name": "authlib",
        "resource": "authlib",
        "strategy": "registry",
        "subject_version": "1.8.0"
      }
    ]
  },
  "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": "BREW-kimi-cli-CVE-2026-114616",
  "modified": "2026-10-30T10:26:52Z",
  "published": "2026-10-29T23:30:56Z",
  "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.7.3",
  "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)",
  "upstream": [
    "GHSA-8m4g-j4wp-wgcg",
    "CVE-2026-114616",
    "PYSEC-2026-4356"
  ]
}

BREW-MCP-ATLASSIAN-CVE-2… (GHSA-8M4G-J4WP-WGCG)

Vulnerability from osv_homebrew – Published: 2026-10-29 22:18 – Updated: 2026-10-31 09:19 – Source website

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

References

URL

Type

	https://github.com/authlib/authlib/security/advis…	WEB
	https://nvd.nist.gov/vuln/detail/CVE-2026-114616	ADVISORY
	https://github.com/authlib/authlib/commit/4ff30db…	WEB
	https://github.com/authlib/authlib	PACKAGE
	https://github.com/authlib/authlib/releases/tag/v1.9.1	WEB

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": "bump",
        "range_state": "fixed",
        "resource": "authlib",
        "resource_purl": "pkg:pypi/authlib@1.9.1",
        "upstream_fixed_in": "1.9.1"
      },
      "package": {
        "ecosystem": "Homebrew",
        "name": "mcp-atlassian",
        "purl": "pkg:brew/mcp-atlassian"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.11.11"
            },
            {
              "fixed": "0.23.1_2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "confidence": "high",
    "source": "matched",
    "strategy": "registry",
    "upstream_evidence": [
      {
        "ecosystem": "PyPI",
        "key": "pkg:pypi/authlib@1.9.1",
        "name": "authlib",
        "resource": "authlib",
        "strategy": "registry",
        "subject_version": "1.9.1"
      }
    ]
  },
  "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": "BREW-mcp-atlassian-CVE-2026-114616",
  "modified": "2026-10-31T09:19:49Z",
  "published": "2026-10-29T22:18:19Z",
  "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.7.3",
  "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)",
  "upstream": [
    "GHSA-8m4g-j4wp-wgcg",
    "CVE-2026-114616",
    "PYSEC-2026-4356"
  ]
}

BREW-MCPM-CVE-2026-114616 (GHSA-8M4G-J4WP-WGCG)

Vulnerability from osv_homebrew – Published: 2026-10-29 23:23 – Updated: 2026-10-31 10:32 – Source website

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

References

URL

Type

	https://github.com/authlib/authlib/security/advis…	WEB
	https://nvd.nist.gov/vuln/detail/CVE-2026-114616	ADVISORY
	https://github.com/authlib/authlib/commit/4ff30db…	WEB
	https://github.com/authlib/authlib	PACKAGE
	https://github.com/authlib/authlib/releases/tag/v1.9.1	WEB

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": "bump",
        "range_state": "fixed",
        "resource": "authlib",
        "resource_purl": "pkg:pypi/authlib@1.9.1",
        "upstream_fixed_in": "1.9.1"
      },
      "package": {
        "ecosystem": "Homebrew",
        "name": "mcpm",
        "purl": "pkg:brew/mcpm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.1.0"
            },
            {
              "fixed": "2.15.0_5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "confidence": "high",
    "source": "matched",
    "strategy": "registry",
    "upstream_evidence": [
      {
        "ecosystem": "PyPI",
        "key": "pkg:pypi/authlib@1.9.1",
        "name": "authlib",
        "resource": "authlib",
        "strategy": "registry",
        "subject_version": "1.9.1"
      }
    ]
  },
  "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": "BREW-mcpm-CVE-2026-114616",
  "modified": "2026-10-31T10:32:15Z",
  "published": "2026-10-29T23:23:34Z",
  "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.7.3",
  "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)",
  "upstream": [
    "GHSA-8m4g-j4wp-wgcg",
    "CVE-2026-114616",
    "PYSEC-2026-4356"
  ]
}

BREW-OMNARA-CVE-2026-114616 (GHSA-8M4G-J4WP-WGCG)

Vulnerability from osv_homebrew – Published: 2026-10-29 22:13 – Updated: 2026-10-31 09:18 – Source website

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

References

URL

Type

	https://github.com/authlib/authlib/security/advis…	WEB
	https://nvd.nist.gov/vuln/detail/CVE-2026-114616	ADVISORY
	https://github.com/authlib/authlib/commit/4ff30db…	WEB
	https://github.com/authlib/authlib	PACKAGE
	https://github.com/authlib/authlib/releases/tag/v1.9.1	WEB

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": null,
        "range_state": "affected",
        "resource": "authlib",
        "resource_purl": "pkg:pypi/authlib@1.6.6",
        "upstream_fixed_in": "1.9.1"
      },
      "package": {
        "ecosystem": "Homebrew",
        "name": "omnara",
        "purl": "pkg:brew/omnara"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.5.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "confidence": "high",
    "source": "matched",
    "strategy": "registry",
    "upstream_evidence": [
      {
        "ecosystem": "PyPI",
        "key": "pkg:pypi/authlib@1.6.6",
        "name": "authlib",
        "resource": "authlib",
        "strategy": "registry",
        "subject_version": "1.6.6"
      }
    ]
  },
  "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": "BREW-omnara-CVE-2026-114616",
  "modified": "2026-10-31T09:18:07Z",
  "published": "2026-10-29T22:13:09Z",
  "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.7.3",
  "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)",
  "upstream": [
    "GHSA-8m4g-j4wp-wgcg",
    "CVE-2026-114616",
    "PYSEC-2026-4356"
  ]
}

BREW-OTERM-CVE-2026-114616 (GHSA-8M4G-J4WP-WGCG)

Vulnerability from osv_homebrew – Published: 2026-10-29 21:42 – Updated: 2026-10-31 09:09 – Source website

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

References

URL

Type

	https://github.com/authlib/authlib/security/advis…	WEB
	https://nvd.nist.gov/vuln/detail/CVE-2026-114616	ADVISORY
	https://github.com/authlib/authlib/commit/4ff30db…	WEB
	https://github.com/authlib/authlib	PACKAGE
	https://github.com/authlib/authlib/releases/tag/v1.9.1	WEB

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": "bump",
        "range_state": "fixed",
        "resource": "authlib",
        "resource_purl": "pkg:pypi/authlib@1.9.1",
        "upstream_fixed_in": "1.9.1"
      },
      "package": {
        "ecosystem": "Homebrew",
        "name": "oterm",
        "purl": "pkg:brew/oterm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.14.0"
            },
            {
              "fixed": "0.26.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "confidence": "high",
    "source": "matched",
    "strategy": "registry",
    "upstream_evidence": [
      {
        "ecosystem": "PyPI",
        "key": "pkg:pypi/authlib@1.9.1",
        "name": "authlib",
        "resource": "authlib",
        "strategy": "registry",
        "subject_version": "1.9.1"
      }
    ]
  },
  "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": "BREW-oterm-CVE-2026-114616",
  "modified": "2026-10-31T09:09:54Z",
  "published": "2026-10-29T21:42:43Z",
  "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.7.3",
  "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)",
  "upstream": [
    "GHSA-8m4g-j4wp-wgcg",
    "CVE-2026-114616",
    "PYSEC-2026-4356"
  ]
}

BREW-SAFETY-CVE-2026-114616 (GHSA-8M4G-J4WP-WGCG)

Vulnerability from osv_homebrew – Published: 2026-10-29 21:42 – Updated: 2026-10-31 08:46 – Source website

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

References

URL

Type

	https://github.com/authlib/authlib/security/advis…	WEB
	https://nvd.nist.gov/vuln/detail/CVE-2026-114616	ADVISORY
	https://github.com/authlib/authlib/commit/4ff30db…	WEB
	https://github.com/authlib/authlib	PACKAGE
	https://github.com/authlib/authlib/releases/tag/v1.9.1	WEB

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": "bump",
        "range_state": "fixed",
        "resource": "authlib",
        "resource_purl": "pkg:pypi/authlib@1.9.1",
        "upstream_fixed_in": "1.9.1"
      },
      "package": {
        "ecosystem": "Homebrew",
        "name": "safety",
        "purl": "pkg:brew/safety"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.2.4"
            },
            {
              "fixed": "3.8.1_3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "confidence": "high",
    "source": "matched",
    "strategy": "registry",
    "upstream_evidence": [
      {
        "ecosystem": "PyPI",
        "key": "pkg:pypi/authlib@1.9.1",
        "name": "authlib",
        "resource": "authlib",
        "strategy": "registry",
        "subject_version": "1.9.1"
      }
    ]
  },
  "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": "BREW-safety-CVE-2026-114616",
  "modified": "2026-10-31T08:46:31Z",
  "published": "2026-10-29T21:42:00Z",
  "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.7.3",
  "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)",
  "upstream": [
    "GHSA-8m4g-j4wp-wgcg",
    "CVE-2026-114616",
    "PYSEC-2026-4356"
  ]
}

BREW-WEAVIATE-CLI-CVE-20… (GHSA-8M4G-J4WP-WGCG)

Vulnerability from osv_homebrew – Published: 2026-10-29 21:46 – Updated: 2026-10-31 09:57 – Source website

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

References

URL

Type

	https://github.com/authlib/authlib/security/advis…	WEB
	https://nvd.nist.gov/vuln/detail/CVE-2026-114616	ADVISORY
	https://github.com/authlib/authlib/commit/4ff30db…	WEB
	https://github.com/authlib/authlib	PACKAGE
	https://github.com/authlib/authlib/releases/tag/v1.9.1	WEB

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": "bump",
        "range_state": "fixed",
        "resource": "authlib",
        "resource_purl": "pkg:pypi/authlib@1.9.1",
        "upstream_fixed_in": "1.9.1"
      },
      "package": {
        "ecosystem": "Homebrew",
        "name": "weaviate-cli",
        "purl": "pkg:brew/weaviate-cli"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.2"
            },
            {
              "fixed": "3.4.2_1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "confidence": "high",
    "source": "matched",
    "strategy": "registry",
    "upstream_evidence": [
      {
        "ecosystem": "PyPI",
        "key": "pkg:pypi/authlib@1.9.1",
        "name": "authlib",
        "resource": "authlib",
        "strategy": "registry",
        "subject_version": "1.9.1"
      }
    ]
  },
  "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": "BREW-weaviate-cli-CVE-2026-114616",
  "modified": "2026-10-31T09:57:52Z",
  "published": "2026-10-29T21:46:15Z",
  "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.7.3",
  "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)",
  "upstream": [
    "GHSA-8m4g-j4wp-wgcg",
    "CVE-2026-114616",
    "PYSEC-2026-4356"
  ]
}

FKIE_CVE-2026-114616

Vulnerability from fkie_nvd - Published: 2026-10-22 22:18 - Updated: 2026-10-30 20:17

Severity

7.4 (High) - CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
9.1 (Critical) - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

Summary

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.

References

URL	Tags
security-advisories@github.com	https://github.com/authlib/authlib/commit/4ff30db442c70e29486e1982cb0ad37c037f5f4b	Patch
security-advisories@github.com	https://github.com/authlib/authlib/releases/tag/v1.9.1	Release Notes
security-advisories@github.com	https://github.com/authlib/authlib/security/advisories/GHSA-8m4g-j4wp-wgcg	Exploit, Mitigation, Vendor Advisory

Impacted products

	Vendor	Product	Version
	authlib	authlib	*

JSON

To clipboard

{
  "affected": [
    {
      "affectedData": [
        {
          "product": "authlib",
          "vendor": "authlib",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 1.9.1"
            }
          ]
        }
      ],
      "source": "security-advisories@github.com"
    }
  ],
  "configurations": [
    {
      "nodes": [
        {
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:a:authlib:authlib:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "1B8ABFEA-DEC5-4258-948D-BFD99A9997E0",
              "versionEndExcluding": "1.9.1",
              "vulnerable": true
            }
          ],
          "negate": false,
          "operator": "OR"
        }
      ]
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "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": "CVE-2026-114616",
  "lastModified": "2026-10-30T20:17:00.643",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "HIGH",
          "attackVector": "NETWORK",
          "availabilityImpact": "NONE",
          "baseScore": 7.4,
          "baseSeverity": "HIGH",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "HIGH",
          "privilegesRequired": "NONE",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
          "version": "3.1"
        },
        "exploitabilityScore": 2.2,
        "impactScore": 5.2,
        "source": "security-advisories@github.com",
        "type": "Secondary"
      },
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "NETWORK",
          "availabilityImpact": "NONE",
          "baseScore": 9.1,
          "baseSeverity": "CRITICAL",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "HIGH",
          "privilegesRequired": "NONE",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
          "version": "3.1"
        },
        "exploitabilityScore": 3.9,
        "impactScore": 5.2,
        "source": "nvd@nist.gov",
        "type": "Primary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2026-114616",
          "options": [
            {
              "exploitation": "none"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "total"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2026-10-30T20:07:25.381279Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2026-10-22T22:18:04.420",
  "references": [
    {
      "source": "security-advisories@github.com",
      "tags": [
        "Patch"
      ],
      "url": "https://github.com/authlib/authlib/commit/4ff30db442c70e29486e1982cb0ad37c037f5f4b"
    },
    {
      "source": "security-advisories@github.com",
      "tags": [
        "Release Notes"
      ],
      "url": "https://github.com/authlib/authlib/releases/tag/v1.9.1"
    },
    {
      "source": "security-advisories@github.com",
      "tags": [
        "Exploit",
        "Mitigation",
        "Vendor Advisory"
      ],
      "url": "https://github.com/authlib/authlib/security/advisories/GHSA-8m4g-j4wp-wgcg"
    }
  ],
  "sourceIdentifier": "security-advisories@github.com",
  "vulnStatus": "Analyzed",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-287"
        },
        {
          "lang": "en",
          "value": "CWE-326"
        },
        {
          "lang": "en",
          "value": "CWE-1391"
        }
      ],
      "source": "security-advisories@github.com",
      "type": "Secondary"
    }
  ]
}

CVE-2026-114616 (GCVE-0-2026-114616)

Tags

Sightings

Nomenclature

Vulnerability timeline

Related by attack behaviour

Action not permitted

CVE-2026-114616 (GCVE-0-2026-114616)

BREW-FASTMCP-CVE-2026-114616 (GHSA-8M4G-J4WP-WGCG)

BREW-KASKADE-CVE-2026-114616 (GHSA-8M4G-J4WP-WGCG)

BREW-KIMI-CLI-CVE-2026-114616 (GHSA-8M4G-J4WP-WGCG)

BREW-MCP-ATLASSIAN-CVE-2… (GHSA-8M4G-J4WP-WGCG)

BREW-MCPM-CVE-2026-114616 (GHSA-8M4G-J4WP-WGCG)

BREW-OMNARA-CVE-2026-114616 (GHSA-8M4G-J4WP-WGCG)

BREW-OTERM-CVE-2026-114616 (GHSA-8M4G-J4WP-WGCG)

BREW-SAFETY-CVE-2026-114616 (GHSA-8M4G-J4WP-WGCG)

BREW-WEAVIATE-CLI-CVE-20… (GHSA-8M4G-J4WP-WGCG)

FKIE_CVE-2026-114616

Tags

Sightings

Nomenclature

Vulnerability timeline

Related by attack behaviour