You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in ParseWithClaims can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by ParseWithClaims return both error codes. If users only check for the jwt.ErrTokenExpired using error.Is, they will ignore the embedded jwt.ErrTokenSignatureInvalid and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the v5 branch to the v4 branch. In this logic, the ParseWithClaims function will immediately return in "dangerous" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors ("dangerous" ones first), so that you are not running in the case detailed above.
CVE-2024-51744 - Low Severity Vulnerability
Vulnerable Library - github.com/golang-JWT/jwt-v3.2.2+incompatible
Library home page: https://proxy.golang.org/github.com/golang-!j!w!t/jwt/@v/v3.2.2+incompatible.zip
Path to dependency file: /go.mod
Path to vulnerable library: /go.mod
Dependency Hierarchy:
Found in base branch: dev
Vulnerability Details
golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in
ParseWithClaims
can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned byParseWithClaims
return both error codes. If users only check for thejwt.ErrTokenExpired
usingerror.Is
, they will ignore the embeddedjwt.ErrTokenSignatureInvalid
and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from thev5
branch to thev4
branch. In this logic, theParseWithClaims
function will immediately return in "dangerous" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors ("dangerous" ones first), so that you are not running in the case detailed above.Publish Date: 2024-11-04
URL: CVE-2024-51744
CVSS 3 Score Details (3.1)
Base Score Metrics:
Suggested Fix
Type: Upgrade version
Origin: GHSA-29wx-vh33-7x7r
Release Date: 2024-11-04
Fix Resolution: github.com/golang-jwt/jwt-v4.5.1
Step up your Open Source Security Game with Mend here
The text was updated successfully, but these errors were encountered: