Affected: PyPI: pyjwt

### Summary

`HMACAlgorithm.from_jwk` accepts a symmetric (`kty=oct`) JWK whose `k` value is the empty string and returns a zero-length key without raising. When a token is then verified with that key object (a `PyJWK`, or a `PyJWK` resolved by `PyJWKSet` / `PyJWKClient`), the HMAC verifier computes `HMAC(key=b"", signing_input)` and accepts any token an attacker forged with the same empty key. The attacker needs no secret knowledge: they reproduce the digest locally with an empty key and set the token's `kid` to the empty-`k` JWK.

The empty-key rejection that `HMACAlgorithm.prepare_key` performs for string/bytes secrets (added in 2.13.0) was never propagated to the sibling `from_jwk` code path, so the JWK/JWKS verification route stays exploitable. Under default decode options this path only emits an `InsecureKeyLengthWarning`, not an error, so verification still succeeds. This is the same "empty/nil HMAC key is accepted by verify" defect the JWT ecosystem is currently closing library-side: fast-jwt CVE-2026-44351 (CVSS 9.1) and ruby-jwt CVE-2026-45363 both added a library-side reject-empty-HMAC-key precondition.

### Affected versions

`PyJWT` (PyPI package `pyjwt`) `<= 2.13.0`, current `master` at commit `7144e4534c34810f4525dc4578a32addd8212cff`. The string/bytes secret path is already guarded in 2.13.0; the JWK/JWKS path is not.

### Privilege required

Unauthenticated. Any party who can reach a JWT-verifying endpoint of an application that verifies via a `PyJWK` / `PyJ…