CVE-2024-9681: Haxx Curl HSTS Cache Corruption Vulnerability

CVE-2024-9681 Overview

CVE-2024-9681 is an improper comparison vulnerability in curl's HTTP Strict Transport Security (HSTS) cache implementation. When curl is configured to use HSTS, the expiry time for a subdomain might incorrectly overwrite a parent domain's cache entry, causing the HSTS policy to end sooner or later than intended. This flaw affects applications that enable HSTS, use URLs with the insecure HTTP:// scheme, and perform transfers with both subdomain hosts (e.g., x.example.com) and their parent domains (e.g., example.com).

The vulnerability is triggered when a subdomain responds with Strict-Transport-Security: headers, causing the subdomain's expiry timeout to "bleed over" and incorrectly set the expiry for the parent domain in curl's HSTS cache. This can result in HTTP accesses to the parent domain being converted to HTTPS for a different period than originally specified by the server, or cause premature expiration of the parent's HSTS entry, potentially switching traffic back to insecure HTTP earlier than intended.

Critical Impact

HSTS cache manipulation could result in premature downgrade from HTTPS to insecure HTTP connections, exposing users to man-in-the-middle attacks and data interception.

Affected Products

• haxx curl (all versions prior to patch)

Discovery Timeline

• 2024-11-06 - CVE-2024-9681 published to NVD
• 2025-11-03 - Last updated in NVD database

Technical Details for CVE-2024-9681

Vulnerability Analysis

This vulnerability stems from an improper comparison issue (CWE-697) in curl's HSTS cache management logic. The HSTS feature is designed to enforce secure HTTPS connections for domains that have previously indicated support via the Strict-Transport-Security header. However, when processing HSTS headers from subdomain responses, curl fails to properly isolate cache entries between subdomains and their parent domains.

The bug requires specific conditions to manifest: the HSTS cache must already contain entries for the domains involved (either populated manually or through previous HTTPS accesses), and the application must make requests to both a subdomain and its parent domain using insecure HTTP URLs. When these conditions are met, the subdomain's HSTS expiry time can overwrite the parent domain's cache entry.

The practical impact is two-fold. First, if a parent domain stops supporting HTTPS at its intended expiry time but curl has recorded a longer timeout from a subdomain, subsequent HTTP requests will incorrectly attempt HTTPS and fail. Second, if the subdomain's expiry is shorter, curl may prematurely switch back to insecure HTTP, eliminating the security benefits of HSTS and potentially exposing traffic to interception.

Root Cause

The root cause is an improper comparison flaw (CWE-697) in curl's HSTS cache lookup and update logic. When storing HSTS expiry information, curl incorrectly matches subdomain entries against parent domain cache keys, allowing expiry times to cross domain boundaries. This comparison error violates the domain isolation principles that HSTS relies upon for security.

Attack Vector

This vulnerability has a network-based attack vector that requires an attacker to be in a position to serve HSTS headers from a subdomain. An attacker controlling a subdomain (or able to inject HSTS headers into subdomain responses) can manipulate the HSTS expiry time for the parent domain. This could be exploited to:

1. Force premature HSTS expiration on a parent domain, enabling downgrade attacks
2. Extend HSTS expiry inappropriately, causing connection failures if the parent domain stops HTTPS support
3. Create denial-of-service conditions by manipulating cache timing

The attack requires no user interaction beyond normal browsing activity and exploits the trust relationship between domains and subdomains in the HSTS implementation.

Detection Methods for CVE-2024-9681

Indicators of Compromise

• Unexpected HSTS cache entries with expiry times that don't match server-specified values
• Connection failures to parent domains that recently supported HTTPS
• Anomalous HTTP traffic to domains that should be HSTS-protected
• Unexplained downgrades from HTTPS to HTTP for previously secure connections

Detection Strategies

• Monitor curl version deployments across infrastructure and flag unpatched instances
• Implement network monitoring to detect unexpected HTTP connections to HSTS-protected domains
• Audit HSTS cache files for inconsistencies between subdomain and parent domain expiry times
• Review application logs for connection failures related to HTTPS enforcement

Monitoring Recommendations

• Deploy network security monitoring to detect potential downgrade attacks on HSTS-protected domains
• Implement alerting for curl library version checks in CI/CD pipelines
• Monitor outbound connections for HTTP traffic to domains expected to use HSTS
• Review web server access logs for unusual patterns of HTTP vs HTTPS requests

How to Mitigate CVE-2024-9681

Immediate Actions Required

• Update curl to the latest patched version addressing CVE-2024-9681
• Audit applications using libcurl with HSTS enabled to assess exposure
• Consider temporarily disabling HSTS in curl for critical applications until patching is complete
• Review HSTS cache contents for any signs of manipulation

Patch Information

Patches for this vulnerability are available from the curl project. Organizations should update to the latest curl release that addresses CVE-2024-9681. Detailed patch information and security advisories can be found at the official curl CVE-2024-9681 documentation. Additional details are available via the HackerOne report and the NetApp Security Advisory.

Workarounds

• Disable HSTS support in curl using --no-hsts flag if HTTPS enforcement can be handled at network layer
• Avoid mixed subdomain and parent domain requests in the same curl session when using HSTS
• Implement certificate pinning as an alternative to HSTS for critical connections
• Use explicit HTTPS URLs throughout applications rather than relying on HSTS upgrades

# Disable HSTS in curl as a temporary workaround
curl --no-hsts https://example.com/resource

# Clear HSTS cache to remove potentially corrupted entries
rm ~/.curl-hsts

# Force HTTPS explicitly without relying on HSTS
curl --proto '=https' https://example.com/resource