Prüft ein Dienst RS256-Tokens mit verify(token, publicKeyPem) und akzeptiert die Bibliothek mit jedem übergebenen Schlüssel auch HS256, nimmt ein Angreifer den öffentlichen Schlüssel (im JWKS veröffentlicht), berechnet mit diesen Bytes als Secret einen HMAC über einen gefälschten Header und eine gefälschte Payload und setzt "alg": "HS256"; der Server prüft dann einen gültigen HMAC. Tim McLean beschrieb das 2015 zusammen mit none, und Varianten tauchen in neuen Bibliotheken und Frameworks immer wieder auf, auch über JWKs, die im Header jwk des Tokens eingebettet sind.
Die Abhilfe (RFC 8725 §3.1) besteht darin, jeden Schlüssel auf der Seite des Verifizierers an genau einen Algorithmus zu binden: Allowlists für Algorithmen, typisierte Schlüsselobjekte, die nicht zugleich als HMAC-Secret dienen können, der Parameter alg in jedem JWK, abgeglichen mit dem Token, und keine Auswahl von Schlüsseln aus jwk, jku oder x5u des Tokens ohne Vertrauensentscheidung. Die vollständig spezifizierten Algorithmusnamen aus RFC 9864 beseitigen die verwandte Mehrdeutigkeit polymorpher Bezeichner wie EdDSA.