CVE-2026-48526: PyJWT closes JWK-as-HMAC algorithm confusion at the root

Vulnerability

CVE-2026-48526 describes an algorithm-confusion flaw in PyJWT where a public JWK string can be misused as an HMAC secret, allowing forged tokens to verify if the attacker switches the JWT header to an HS* algorithm. The patch summary and changelog state that the prior defense only rejected PEM/SSH-shaped material, leaving a gap for JSON-encoded JWK input passed into HMACAlgorithm.prepare_key. In that state, asymmetric public-key metadata could be treated as arbitrary bytes, which is exactly the dangerous property of HMAC verification in mixed-algorithm contexts.

The vulnerable condition is therefore not generic JWT misuse but a concrete key-shape validation failure: raw JWK JSON was accepted on the HMAC path even though it is not secret material and should instead be parsed through JWK-aware APIs. This matches the advisory framing in the upstream security notice at GHSA-XGMM-8J9V-C9WX and the upstream fix commit at commit 95791b1759b8aa4f2203575d344d5c78564cdc81.

# Vulnerable behavior pattern described by the patch rationale:
# attacker-controlled header selects HS256
# verifier accepts raw JWK JSON bytes as HMAC secret
# signature verification succeeds against non-secret public material

Patch

The core fix is in jwt/algorithms.py. PyJWT now rejects empty HMAC keys and, more importantly for this CVE, inspects HMAC key bytes for JSON objects containing a kty member. If the supplied value parses as a JWK-like object, prepare_key raises InvalidKeyError and instructs callers to use PyJWK or HMACAlgorithm.from_jwk instead. This is a direct control on the dangerous conversion boundary where arbitrary bytes become an HMAC secret.

if len(key_bytes) == 0:
    raise InvalidKeyError("HMAC key must not be empty.")

stripped = key_bytes.lstrip()
if stripped.startswith(b"{"):
    try:
        jwk_obj = json.loads(key_bytes)
    except ValueError:
        jwk_obj = None
    if isinstance(jwk_obj, dict) and "kty" in jwk_obj:
        raise InvalidKeyError(
            "The specified key looks like a JWK and should not be "
            "used directly as an HMAC secret. Load it via "
            "PyJWK / HMACAlgorithm.from_jwk first."
        )

The associated tests in tests/test_algorithms.py cover RSA, EC, OKP, and HMAC JWK JSON fixtures, and also include a negative control showing that arbitrary JSON without kty is still accepted as a literal secret. That test design is important: it demonstrates the patch is intentionally keyed to JWK structure rather than banning all JSON-like secrets.

Although the same release also includes fixes for other issues in api_jws.py, api_jwt.py, and jwks_client.py, those are separate hardening changes and not required to explain the remediation of CVE-2026-48526. For this CVE specifically, the decisive change is the new JWK rejection logic on the HMAC key preparation path, as documented in the changelog and commit diff at the upstream patch.

Review

Pros

• The fix is placed at the correct trust boundary: HMACAlgorithm.prepare_key is where untyped caller input becomes a symmetric verification key.
• The mitigation is source-aligned with the vulnerability description: it blocks JWK JSON documents specifically, which were the uncovered format left behind by the older PEM/SSH guard.
• Regression coverage is strong for the reported issue. Tests exercise multiple public-key JWK families plus an octet JWK, reducing the chance of format-specific bypasses.
• The patch preserves legitimate non-JWK JSON secrets by checking for parsed-object shape and the presence of kty, avoiding an unnecessarily broad compatibility break.
• Error messaging is actionable, steering developers toward JWK-aware loading APIs instead of silently coercing unsafe input.

Cons

• The detection heuristic is structural rather than semantic. It keys on JSON parsing and a kty field, so it is intentionally narrow and may not catch every possible non-secret representation that could be misused as HMAC input.
• Because arbitrary byte strings remain valid HMAC secrets by design, the library still relies on callers to avoid algorithm mixing and to supply the correct key type for their verification model.
• The patch does not appear to introduce a broader typed-key separation across all decode entry points; instead it blocks the known dangerous JWK-as-secret path. That is appropriate for compatibility, but it means the safety model is still partly convention-based.

Verdict

Root-cause.

The patch directly addresses the vulnerable behavior described for CVE-2026-48526: acceptance of raw JWK JSON as an HMAC secret. By rejecting JWK-shaped JSON before it can be used in symmetric verification, PyJWT removes the specific algorithm-confusion primitive rather than merely filtering a single exploit string or adding a superficial header check. The added tests demonstrate intent and reduce regression risk. Based on the provided sources, this is a technically sound and appropriately scoped upstream fix.