tree a7d6d62b5f6b21df837674617589572aeb5e8419
parent 64a4f448657a209e2735ae4e2377ca43d16cbcf2
author Ben Collins <bcollins@libjwt.io> 1777898960 -0400
committer Ben Collins <benmcollins13@gmail.com> 1777903078 -0400

Fix algorithm confusion that allows JWT forgery via RSA JWK as HMAC key

GHSA-q843-6q5f-w55g: an RSA JWK without an "alg" parameter was accepted
as the verification key for HS256/384/512 tokens. Because the jwk_item_t
union shares storage between provider_data (RSA EVP_PKEY *) and
oct.{key,len} (HMAC bytes/length), the OpenSSL HMAC path read a
zero-length key and produced a successful verification for any token
signed as HMAC("", header.payload). This let an attacker forge tokens
using only the public JWKS.

Bind algorithm acceptance to the JWK's actual "kty" rather than its
optional "alg" hint, in three layered places:

* jwt-private.h: new jwt_alg_required_kty() helper providing the
  authoritative JWA-algorithm to JWK-kty mapping.
* jwt-common.c: __setkey_check() now rejects any setkey() / verify
  callback that pairs a non-none algorithm with an incompatible kty.
  This is the primary fix and runs at both setkey and post-callback.
* jwt-verify.c: __verify_config_post() re-checks kty once jwt->alg is
  bound from the token, blocking malformed JWKs whose own alg hint
  disagrees with their kty.
* jwt.c: __check_hmac() defensive backstop in the single chokepoint
  used by all three crypto backends; refuses any non-oct key for HMAC.

Tests added in jwt_security.c cover the original PoC, the realistic
JWKS callback exploit pattern, all three HS sizes, RSA/EC/OKP keys
mis-targeted at HS256, and the malformed-JWK defensive verify path.
A few existing tests (hs256_token_failed, verify_es256_bad_sig,
sign_es256_bad_sig, rsa_ec_short) were updated; they previously
documented the vulnerable behavior under the guise of "different ways"
of failing and now assert the correct earlier rejection.

Signed-off-by: Ben Collins <bcollins@libjwt.io>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>