CVE-2024-0853: Haxx Curl Auth Bypass Vulnerability

CVE-2024-0853 Overview

CVE-2024-0853 is a certificate validation bypass vulnerability affecting curl version 8.5.0. The vulnerability occurs when curl inadvertently retains SSL session IDs in its cache even after an OCSP stapling verification failure. When a subsequent connection is made to the same hostname, curl may reuse the cached session ID, effectively bypassing the certificate revocation status check that should have prevented the connection.

This flaw is classified under CWE-295 (Improper Certificate Validation) and represents a significant security concern for applications relying on curl for secure communications with proper certificate revocation checking.

Critical Impact

Connections to servers with revoked certificates may succeed if the SSL session cache contains a valid session ID from a previous connection, undermining the security guarantees of OCSP stapling verification.

Affected Products

• Haxx curl version 8.5.0

Discovery Timeline

• 2024-02-03 - CVE-2024-0853 published to NVD
• 2025-06-20 - Last updated in NVD database

Technical Details for CVE-2024-0853

Vulnerability Analysis

The vulnerability exists in curl's SSL session caching mechanism when OCSP stapling is enabled. OCSP (Online Certificate Status Protocol) stapling is a security feature where the server provides a signed, timestamped response from the Certificate Authority proving the certificate hasn't been revoked. When this verification fails, curl should reject the connection entirely and discard any associated session data.

However, in curl 8.5.0, the SSL session ID is erroneously retained in the cache even when the OCSP stapling verification fails. SSL session resumption is a TLS optimization that allows clients to skip the full handshake on subsequent connections by presenting a previously negotiated session ID. The problem arises because session resumption bypasses the certificate verification process entirely—including OCSP checking—since the session was already validated in the original handshake.

This creates a window where an attacker controlling a server with a revoked certificate could potentially establish a trusted connection if the client previously connected to that hostname before the certificate was revoked.

Root Cause

The root cause is improper handling of the SSL session cache when certificate validation fails. The session ID should be invalidated and removed from the cache whenever any part of the certificate verification chain fails, including OCSP stapling checks. The code path that handles OCSP verification failures did not properly clear the session cache entry, allowing subsequent connections to reuse the compromised session.

Attack Vector

The attack requires network access and operates through the following mechanism:

1. The victim's curl client connects to a legitimate server and caches the SSL session ID
2. The server's certificate is subsequently revoked (due to compromise, key exposure, etc.)
3. An attacker obtains control of the server or performs a man-in-the-middle attack
4. On subsequent connections, curl attempts session resumption using the cached session ID
5. Because session resumption skips certificate verification, the OCSP stapling check that would detect the revoked certificate is bypassed
6. The connection succeeds despite the certificate being revoked

The attack window exists while the session cache remains fresh. The integrity of subsequent communications could be compromised as the client believes it has a secure connection to a server with a valid certificate.

Detection Methods for CVE-2024-0853

Indicators of Compromise

• Successful SSL/TLS connections to hosts where OCSP stapling verification previously failed
• Curl verbose logs showing session resumption (SSL re-using session ID) for connections that should have fresh certificate validation
• Unexpected session cache hits for connections to servers with known certificate issues

Detection Strategies

• Enable curl verbose logging (-v or --verbose) to monitor SSL session behavior
• Audit application logs for patterns indicating session reuse after certificate warnings
• Monitor network traffic for TLS session resumption handshakes to previously problematic hosts
• Implement certificate transparency log monitoring to detect revoked certificates in use

Monitoring Recommendations

• Configure logging to capture all SSL/TLS handshake events and OCSP responses
• Set up alerts for certificate revocation events affecting monitored domains
• Review curl usage patterns in automated systems and scripts that may persist sessions
• Monitor for connections to hosts where certificate validation has previously failed

How to Mitigate CVE-2024-0853

Immediate Actions Required

• Upgrade curl to version 8.6.0 or later which contains the fix for this vulnerability
• Clear any existing SSL session caches in curl-based applications
• Audit applications that rely on OCSP stapling for certificate validation
• Consider temporarily disabling session caching if immediate upgrade is not possible

Patch Information

The curl project has addressed this vulnerability in releases following version 8.5.0. Users should upgrade to the latest stable release to receive the fix. Detailed information about the vulnerability and patch is available in the curl.se CVE-2024-0853 Documentation.

Additional security advisories have been issued by downstream vendors:

• NetApp Security Advisory NTAP-20240307-0004
• NetApp Security Advisory NTAP-20240426-0009
• NetApp Security Advisory NTAP-20240503-0012

The original vulnerability was reported via HackerOne Report #2298922.

Workarounds

• Disable SSL session ID caching by setting CURLOPT_SSL_SESSIONID_CACHE to 0 (disabled)
• Use --no-sessionid command-line option for curl commands
• Implement application-level certificate validation in addition to curl's built-in checks
• For critical applications, consider using CURLOPT_SSL_VERIFYSTATUS with fresh connections (no session reuse)

# Disable SSL session ID caching in curl commands
curl --no-sessionid https://example.com

# Or programmatically via libcurl option
# CURLOPT_SSL_SESSIONID_CACHE set to 0L