If a service verifies RS256 tokens with verify(token, publicKeyPem) and the library also accepts HS256 with whatever key it is given, an attacker takes the public key (published in the JWKS), computes an HMAC over a forged header and payload with those bytes as the secret and sets "alg": "HS256"; the server then checks a valid HMAC. Tim McLean described it together with none in 2015, and variants keep appearing in new libraries and frameworks, including through JWKs embedded in the token's jwk header.
The fix (RFC 8725 §3.1) is to bind every key to exactly one algorithm on the verifier side: algorithm allowlists, typed key objects that cannot double as HMAC secrets, alg in each JWK checked against the token, and never selecting keys from token-supplied jwk, jku or x5u without a trust decision. RFC 9864's fully specified algorithm names remove the related ambiguity of polymorphic identifiers such as EdDSA.