CVE-2024-28180: Go-jose_project Go-jose DOS Vulnerability

CVE-2024-28180 Overview

CVE-2024-28180 is a denial of service vulnerability in the go-jose package, a Go implementation of the Javascript Object Signing and Encryption (JOSE) set of standards. The vulnerability allows an attacker to send a maliciously crafted JSON Web Encryption (JWE) token containing compressed data that, when processed by the Decrypt or DecryptMulti functions, consumes excessive amounts of memory and CPU resources during decompression.

Critical Impact

Applications using vulnerable versions of go-jose can be rendered unavailable through resource exhaustion attacks when processing malicious JWE tokens, potentially affecting authentication systems and API services that rely on this cryptographic library.

Affected Products

• go-jose versions prior to 4.0.1
• go-jose versions prior to 3.0.3
• go-jose versions prior to 2.6.3
• Fedora Linux distributions with affected go-jose packages

Discovery Timeline

• March 9, 2024 - CVE-2024-28180 published to NVD
• December 3, 2025 - Last updated in NVD database

Technical Details for CVE-2024-28180

Vulnerability Analysis

This vulnerability stems from improper handling of compressed content within JWE tokens. The go-jose library supports JWE content encryption with optional compression (using algorithms like DEFLATE). When a token containing compressed data is processed by the Decrypt or DecryptMulti functions, the library decompresses the payload without adequate bounds checking.

An attacker can exploit this by crafting a JWE token with a small compressed payload that expands to an extremely large size upon decompression—a technique commonly known as a "zip bomb" or "decompression bomb." This asymmetric resource consumption allows attackers with minimal bandwidth to cause significant resource exhaustion on the target server.

The vulnerability is classified under CWE-409 (Improper Handling of Highly Compressed Data), which specifically addresses scenarios where applications fail to properly handle compressed data that has extreme compression ratios.

Root Cause

The root cause of this vulnerability is the absence of decompression size limits in the Decrypt and DecryptMulti functions. Prior to the patch, the library would decompress JWE payloads without checking whether the decompressed size was within reasonable bounds. This allowed attackers to craft payloads where a small compressed input could expand to arbitrarily large amounts of data, exhausting server memory and CPU resources.

Attack Vector

The attack is network-based and requires the attacker to have low-level authentication (as indicated by the CVSS vector). The attacker sends a specially crafted JWE token to any endpoint that processes encrypted JWE data using the vulnerable go-jose library. When the application attempts to decrypt the token, the decompression operation consumes excessive resources.

The attack flow typically involves:

1. Attacker identifies an endpoint accepting JWE tokens that uses go-jose for decryption
2. Attacker crafts a JWE with highly compressible data (e.g., repeated patterns) that achieves extreme compression ratios
3. The malicious JWE is sent to the target application
4. The Decrypt or DecryptMulti function processes the token and attempts to decompress the payload
5. Memory and CPU are consumed proportionally to the decompressed size, potentially causing service degradation or complete denial of service

Detection Methods for CVE-2024-28180

Indicators of Compromise

• Unusual memory consumption spikes in applications processing JWE tokens
• CPU utilization spikes correlating with JWE decryption operations
• Application crashes or out-of-memory errors in services using go-jose
• Increased response times for API endpoints that process encrypted tokens
• Memory allocation failures logged in application or system logs

Detection Strategies

• Monitor application memory usage patterns for sudden, unexplained growth during token processing
• Implement application performance monitoring (APM) to track resource consumption of cryptographic operations
• Use dependency scanning tools to identify vulnerable go-jose versions in your codebase
• Review application logs for decompression-related errors or timeout events
• Deploy runtime application self-protection (RASP) solutions that can detect resource exhaustion patterns

Monitoring Recommendations

• Set up alerting thresholds for memory and CPU usage on services processing JWE tokens
• Implement request-level resource limits and timeouts for token processing operations
• Monitor network traffic for unusually sized encrypted payloads that appear small but cause high processing time
• Track the ratio of request payload size to processing time as an anomaly indicator
• Enable detailed logging for token validation failures and resource-related exceptions

How to Mitigate CVE-2024-28180

Immediate Actions Required

• Upgrade go-jose to patched versions: 4.0.1, 3.0.3, or 2.6.3 depending on your version branch
• Audit your application to identify all locations where Decrypt or DecryptMulti functions are called
• Implement resource limits at the application or infrastructure level to contain potential DoS impact
• Consider temporarily disabling JWE compression if it is not strictly required
• Review and update dependency lock files to ensure patched versions are pulled

Patch Information

The go-jose maintainers have released security patches that introduce decompression size limits. The patched versions now return an error if the decompressed data would exceed 250kB or 10x the compressed size (whichever is larger). This effectively mitigates the decompression bomb attack vector.

Patched versions:

• Version 4.x: Upgrade to 4.0.1 or later
• Version 3.x: Upgrade to 3.0.3 or later
• Version 2.x: Upgrade to 2.6.3 or later

Relevant commits and advisories:

• GitHub Security Advisory GHSA-c5q2-7r4c-mv6g
• Patch commit for v4
• Patch commit for v3
• Patch commit for v2

Workarounds

• Implement request timeout limits for endpoints that process JWE tokens to prevent long-running decompression operations
• Deploy rate limiting on endpoints accepting encrypted tokens to reduce the attack surface
• Add application-level memory limits using container resource constraints or process memory limits
• Consider using JWE without compression if the compression feature is not essential for your use case
• Implement input validation to reject JWE tokens with compression headers if compression is not expected

# Example: Update go-jose dependency in Go modules
go get github.com/go-jose/go-jose/v4@v4.0.1
go mod tidy
go mod verify