Si un servicio verifica tokens RS256 con verify(token, publicKeyPem) y la biblioteca también acepta HS256 con cualquier clave que reciba, un atacante toma la clave pública (publicada en el JWKS), calcula un HMAC sobre un encabezado y una carga útil falsificados usando esos bytes como secreto y pone "alg": "HS256"; el servidor comprueba entonces un HMAC válido. Tim McLean lo describió junto con none en 2015, y siguen apareciendo variantes en bibliotecas y frameworks nuevos, también a través de JWK incrustadas en el encabezado jwk del token.
La solución (RFC 8725 §3.1) es vincular cada clave a exactamente un algoritmo en el lado del verificador: listas de algoritmos permitidos, objetos de clave tipados que no puedan servir también como secretos HMAC, el alg de cada JWK comparado con el del token y nunca elegir claves a partir de jwk, jku o x5u proporcionados por el token sin una decisión de confianza. Los nombres de algoritmo totalmente especificados del RFC 9864 eliminan la ambigüedad relacionada de los identificadores polimórficos como EdDSA.