CVE-2024-51744

What it actually does

ParseWithClaims returns combined errors for tokens that are both expired and signature-invalid; code that only inspects jwt.ErrTokenExpired via error.Is therefore ignores the embedded signature error and accepts invalid tokens.

Why it matters to the business

Attackers can bypass authentication controls in any application that relies on this library for token validation, potentially gaining unauthorized access to protected resources or user accounts.

How an attack unfolds

An attacker generates a JWT whose signature does not validate yet also carries an expired claim, submits it to an endpoint that calls ParseWithClaims, and succeeds when the application only checks error.Is(jwt.ErrTokenExpired) without also validating the signature error first.

How to fix it

Upgrade golang-jwt/jwt to release 4.5.1 (commit 7b1c1c00a171c6c79bbdb40e4ce7d197060c1c2c) or later; if immediate upgrade is impossible, rewrite all call sites to check dangerous errors such as ErrTokenSignatureInvalid before checking ErrTokenExpired.

How to confirm the fix worked

After upgrade, run unit tests that submit both valid-signature/expired tokens and invalid-signature tokens and confirm only the former produce a non-nil token; scan source for direct calls to ParseWithClaims and ensure error handling inspects all returned error values.

Typical attack path

1. Locate services that import golang-jwt/jwt and call ParseWithClaims
2. Craft a token containing an expired 'exp' claim but an invalid signature
3. Send the token in the expected authentication header or parameter
4. Bypass validation if the calling code only inspects the expired error

How to detect it

Search application logs and source repositories for calls to ParseWithClaims that test only ErrTokenExpired; review authentication success events that coincide with tokens containing invalid signatures or mismatched claims.

What your security team should do

• Prioritize upgrade of golang-jwt/jwt to 4.5.1 across all repositories and rebuild affected binaries
• Add static-analysis or lint rules that flag use of ParseWithClaims without exhaustive error checks
• Review authentication middleware for similar partial error handling patterns
• Monitor dependency update pipelines for the corrected release and enforce its adoption