Since "algorithm" isn't enforced in jwt.decode()in jwt-simple 0.3.0 and earlier, a malicious user could choose what algorithm is sent sent to the server. If the server is expecting RSA but is sent HMAC-SHA with RSA's public key, the server will think the public key is actually an HMAC private key. This could be used to forge any data an attacker wants.

A time-sensitive equality check on the JWT signature in the JsonWebToken.validate method in main/scala/authentikat/jwt/JsonWebToken.scala in authentikat-jwt (aka com.jason-goodwin/authentikat-jwt) version 0.4.5 and earlier allows the supplier of a JWT token to guess bit after bit of the signature by repeating validation requests.

In PyJWT 1.5.0 and below the `invalid_strings` check in `HMACAlgorithm.prepare_key` does not account for all PEM encoded public keys. Specifically, the PKCS1 PEM encoded format would be allowed because it is prefaced with the string `-----BEGIN RSA PUBLIC KEY-----` which is not accounted for. This enables symmetric/asymmetric key confusion attacks against users using the PKCS1 PEM encoded public keys, which would allow an attacker to craft JWTs from scratch.

The verify function in Encryption/Symmetric.php in Malcolm Fell jwt before 1.0.3 does not use a timing-safe function for hash comparison, which allows attackers to spoof signatures via a timing attack.