perl-CRYPT-JWT 0.022 and earlier is affected by: Incorrect Access Control. The impact is: bypass authentication. The component is: JWT.pm for JWT security token, line 614 in _decode_jws(). The attack vector is: network connectivity(crafting user-controlled input to bypass authentication). The fixed version is: 0.023.

Perl Crypt::JWT prior to 0.023 is affected by: Incorrect Access Control. The impact is: allow attackers to bypass authentication by providing a token by crafting with hmac(). The component is: JWT.pm, line 614. The attack vector is: network connectivity. The fixed version is: after commit b98a59b42ded9f9e51b2560410106207c2152d6c.

Auth0 Auth0-WCF-Service-JWT before 1.0.4 leaks the expected JWT signature in an error message when it cannot successfully validate the JWT signature. If this error message is presented to an attacker, they can forge an arbitrary JWT token that will be accepted by the vulnerable application.

Nov json-jwt version >= 0.5.0 && < 1.9.4 contains a CWE-347: Improper Verification of Cryptographic Signature vulnerability in Decryption of AES-GCM encrypted JSON Web Tokens that can result in Attacker can forge a authentication tag. This attack appear to be exploitable via network connectivity. This vulnerability appears to have been fixed in 1.9.4 and later.

inversoft prime-jwt version prior to commit abb0d479389a2509f939452a6767dc424bb5e6ba contains a CWE-20 vulnerability in JWTDecoder.decode that can result in an incorrect signature validation of a JWT token. This attack can be exploitable when an attacker crafts a JWT token with a valid header using 'none' as algorithm and a body to requests it be validated. This vulnerability was fixed after commit abb0d479389a2509f939452a6767dc424bb5e6ba.

Auth0 angular-jwt before 0.1.10 treats whiteListedDomains entries as regular expressions, which allows remote attackers with knowledge of the jwtInterceptorProvider.whiteListedDomains setting to bypass the domain whitelist filter via a crafted domain.

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.

When attempting to allow authentication mode `try` in hapi, hapi-auth-jwt2 version 5.1.1 introduced an issue whereby people could bypass authentication.

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.

inversoft prime-jwt version prior to version 1.3.0 or prior to commit 0d94dcef0133d699f21d217e922564adbb83a227 contains an input validation vulnerability in JWTDecoder.decode that can result in a JWT that is decoded and thus implicitly validated even if it lacks a valid signature. This attack appear to be exploitable via an attacker crafting a token with a valid header and body and then requests it to be validated. This vulnerability appears to have been fixed in 1.3.0 and later or after commit 0d94dcef0133d699f21d217e922564adbb83a227.