CVE-2024-51744: golang-jwt Auth Bypass Vulnerability

CVE-2024-51744 Overview

CVE-2024-51744 is an Improper Input Validation vulnerability in golang-jwt, a widely used Go implementation of JSON Web Tokens (JWT). The vulnerability stems from unclear documentation of error behavior in the ParseWithClaims function, which can lead to developers improperly checking for errors and potentially accepting invalid tokens.

The core issue arises when a token is both expired and has an invalid signature. In this scenario, ParseWithClaims returns both error codes simultaneously. If developers only check for jwt.ErrTokenExpired using error.Is, they may inadvertently ignore the embedded jwt.ErrTokenSignatureInvalid error, leading to the acceptance of tokens that should be rejected.

Critical Impact

Applications using golang-jwt v4 that improperly handle compound errors from ParseWithClaims may accept tokens with invalid signatures, potentially allowing unauthorized access or authentication bypass.

Affected Products

• golang-jwt v4 (versions prior to 4.5.1)
• Applications using the ParseWithClaims function with incomplete error checking

Discovery Timeline

• 2024-11-04 - CVE CVE-2024-51744 published to NVD
• 2024-11-05 - Last updated in NVD database

Technical Details for CVE-2024-51744

Vulnerability Analysis

This vulnerability is classified under CWE-755 (Improper Handling of Exceptional Conditions). The fundamental issue lies in how the ParseWithClaims function returns multiple errors when a JWT token fails validation for multiple reasons. The function can return compound errors containing both jwt.ErrTokenExpired and jwt.ErrTokenSignatureInvalid simultaneously.

The problem becomes critical when developers use Go's errors.Is() function to check only for token expiration. Since the error wrapping mechanism in Go allows multiple errors to be combined, checking for just one error type while ignoring others creates a security gap. An attacker could craft a token with an invalid signature but with an expired timestamp, and if the application only checks for expiration errors first, it might process the token as merely "expired" rather than "invalid."

Root Cause

The root cause is improper error handling logic in the golang-jwt v4 library combined with insufficient documentation about the compound error behavior. The ParseWithClaims function did not prioritize "dangerous" errors (like signature validation failures) over less critical ones (like expiration), allowing both to be returned simultaneously without clear guidance on proper handling order.

Attack Vector

This vulnerability is exploitable over the network. An attacker can craft a malicious JWT token with an invalid signature but valid-looking structure. If the target application checks for token expiration before signature validity (or only checks for expiration), the attacker can bypass signature verification:

1. Attacker intercepts or crafts a JWT token
2. Attacker modifies the token payload while also setting an expired timestamp
3. The modified token has an invalid signature due to payload changes
4. ParseWithClaims returns both ErrTokenExpired and ErrTokenSignatureInvalid
5. Vulnerable application checks only for ErrTokenExpired and treats it as a recoverable error
6. Token with invalid signature is potentially accepted or processed

The following code shows the security patch applied to parser.go:

// ParseWithClaims parses, validates, and verifies like Parse, but supplies a default object
// implementing the Claims interface. This provides default values which can be overridden and
// allows a caller to use their own type, rather than the default MapClaims implementation of
// Claims.
//
// Note: If you provide a custom claim implementation that embeds one of the standard claims (such
// as RegisteredClaims), make sure that a) you either embed a non-pointer version of the claims or
// b) if you are using a pointer, allocate the proper memory for it before passing in the overall
// claims, otherwise you might run into a panic.
func (p *Parser) ParseWithClaims(tokenString string, claims Claims, keyFunc Keyfunc) (*Token, error) {
	token, parts, err := p.ParseUnverified(tokenString, claims)
	if err != nil {

Source: GitHub Commit Update

Detection Methods for CVE-2024-51744

Indicators of Compromise

• Authentication logs showing accepted tokens that should have failed validation
• Unusual patterns of token-based authentication attempts with expired tokens
• Application behavior suggesting bypassed signature verification

Detection Strategies

• Audit application code for improper error handling in JWT validation logic
• Search for code patterns that only check for jwt.ErrTokenExpired without checking jwt.ErrTokenSignatureInvalid
• Review dependency manifests for golang-jwt versions prior to 4.5.1
• Implement unit tests that verify proper rejection of tokens with invalid signatures

Monitoring Recommendations

• Enable verbose logging for JWT validation failures to capture all error types returned
• Monitor for authentication anomalies where tokens are accepted despite multiple validation failures
• Set up dependency scanning to alert on vulnerable golang-jwt versions in your codebase

How to Mitigate CVE-2024-51744

Immediate Actions Required

• Upgrade golang-jwt to version 4.5.1 or later immediately
• Review all code paths that use ParseWithClaims to ensure proper error handling
• Prioritize checking for signature validation errors before other error types
• Test token validation logic with tokens that have both expired timestamps and invalid signatures

Patch Information

A fix has been back-ported with error handling logic from the v5 branch to the v4 branch. In this updated logic, the ParseWithClaims function immediately returns in "dangerous" situations (e.g., an invalid signature), limiting combined errors only to situations where the signature is valid but further validation failed.

The fix is available in version 4.5.1. Note that this changes the behavior of the ParseWithClaims function and may not be 100% backwards compatible. For more details, see the GitHub Security Advisory GHSA-29wx-vh33-7x7r.

Workarounds

• If upgrading is not immediately possible, ensure error checking prioritizes dangerous errors first
• Implement custom wrapper functions around ParseWithClaims that properly check for all error types
• Check for jwt.ErrTokenSignatureInvalid before checking for jwt.ErrTokenExpired
• Use errors.Is() to check for multiple error types in the correct priority order

// Recommended error checking pattern for vulnerable versions
token, err := parser.ParseWithClaims(tokenString, claims, keyFunc)
if err != nil {
    // Always check dangerous errors first
    if errors.Is(err, jwt.ErrTokenSignatureInvalid) {
        // Reject immediately - signature is invalid
        return nil, fmt.Errorf("invalid token signature: %w", err)
    }
    if errors.Is(err, jwt.ErrTokenExpired) {
        // Handle expiration after confirming signature is valid
        return nil, fmt.Errorf("token expired: %w", err)
    }
    // Handle other errors
    return nil, err
}