kimi-cli · PyJWT: HS256/384/512 verify accepts empty HMAC key via oct JWK (PyJWK/PyJWKClient) enabling token forgery
Affects kimi-cliSource GCVE Database
CVSS 7.4 High : upgrade to 1.50.0 soon.
Data as of 26 Oct 2026, 19:41 UTC
- Patch
- Available – fixed in 1.50.0
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:NWhat to do
Upgrade kimi-cli to 1.50.0.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
Homebrewkimi-clipkg:brew/kimi-cliOther threats | Affected
| Fixed in
|
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
AI-suggested
A patch is available in kimi-cli version 1.50.0 that fixes this vulnerability. Users should upgrade to version 1.50.0 or later to ensure the empty HMAC key rejection is applied to the JWK verification path. Until patched, ensure that JWKS used for verification do not contain entries with empty 'k' values and avoid misconfiguration that results in empty keys being published or trusted. No other mitigation is documented.
Description
PyJWT versions up to 2.13.0 and current master at commit 7144e4534c34810f4525dc4578a32addd8212cff contain a vulnerability where the HMACAlgorithm.from_jwk method accepts an empty HMAC key from an oct JWK without rejection. This allows an attacker to forge tokens by exploiting the zero-length key acceptance during verification via PyJWK, PyJWKSet, or PyJWKClient. The issue arises because the empty-key rejection added in 2.13.0 for string/bytes keys was not applied to the JWK verification path. The vulnerability requires no authentication but depends on the verifier resolving an empty 'k' value from a JWK, which can occur due to misconfiguration or trusting a JWKS with such an entry. A fix is available in version 1.50.0 of the affected product kimi-cli.