CVE-2022-42915: Haxx Curl Use-After-Free Vulnerability

CVE-2022-42915 Overview

CVE-2022-42915 is a double free vulnerability affecting curl versions 7.77.0 through 7.85.0. When curl is configured to use an HTTP proxy for transfers with non-HTTP(S) URLs, it establishes connections by issuing a CONNECT request to the proxy and then tunneling the protocol through. If the HTTP proxy refuses this request and returns a non-200 status code, flaws in the error/cleanup handling can trigger a double free condition.

Critical Impact

This double free vulnerability can potentially lead to arbitrary code execution or denial of service when curl processes specific URL schemes through an HTTP proxy that rejects the connection.

Affected Products

• Haxx curl (versions 7.77.0 to 7.85.0)
• Fedora Project Fedora (versions 35, 36, 37)
• NetApp H300S/H500S/H700S/H410S Firmware
• NetApp ONTAP 9
• Apple macOS
• Splunk Universal Forwarder

Discovery Timeline

• October 29, 2022 - CVE-2022-42915 published to NVD
• May 7, 2025 - Last updated in NVD database

Technical Details for CVE-2022-42915

Vulnerability Analysis

This vulnerability is classified as CWE-415 (Double Free), a memory corruption issue that occurs when a program attempts to free the same memory location twice. In the context of curl, this occurs during error handling when an HTTP proxy rejects a CONNECT request for non-HTTP protocols.

The vulnerability is triggered through a specific sequence of events: when curl attempts to tunnel a non-HTTP protocol through an HTTP proxy, and that proxy returns a rejection (non-200 status code), the error handling code path incorrectly frees memory that has already been freed. This type of memory corruption can lead to heap corruption, potentially allowing attackers to manipulate program execution flow.

The affected URL schemes include: dict, gopher, gophers, ldap, ldaps, rtmp, rtmps, and telnet. These protocols are commonly used in enterprise environments for directory services (LDAP), legacy information retrieval (Gopher), and multimedia streaming (RTMP).

Root Cause

The root cause lies in flawed error and cleanup handling within curl's proxy connection code. When an HTTP proxy returns a non-200 response to a CONNECT request for non-HTTP URL schemes, the cleanup routines are invoked in an incorrect sequence or with improper state tracking. This results in memory being freed twice—first during error handling and again during subsequent cleanup operations.

The vulnerability was introduced in curl version 7.77.0, suggesting changes made to the proxy handling or connection cleanup logic at that time inadvertently created this condition.

Attack Vector

The attack requires network access and the ability to either control or influence an HTTP proxy's response to CONNECT requests. An attacker could exploit this vulnerability through the following scenario:

1. The victim application uses curl configured with an HTTP proxy
2. The application attempts to access a resource using one of the vulnerable schemes (dict, gopher, gophers, ldap, ldaps, rtmp, rtmps, or telnet)
3. The attacker-controlled or compromised proxy returns a non-200 response to the CONNECT request
4. This triggers the double free condition in curl's error handling code

While the attack complexity is high due to the specific conditions required, successful exploitation could result in code execution with the privileges of the affected application.

Detection Methods for CVE-2022-42915

Indicators of Compromise

• Unexpected crashes in applications using curl with HTTP proxy configurations
• Memory corruption errors in system logs related to curl or libcurl processes
• Unusual proxy connection failures followed by application crashes when accessing LDAP, Gopher, or RTMP resources

Detection Strategies

• Monitor for curl/libcurl usage patterns involving HTTP proxies with non-HTTP URL schemes (dict, gopher, gophers, ldap, ldaps, rtmp, rtmps, telnet)
• Implement memory sanitizer tools (AddressSanitizer, Valgrind) in development and testing environments to detect double free conditions
• Review application logs for repeated proxy connection failures with non-200 status codes followed by crashes
• Use SentinelOne's behavioral AI to detect abnormal memory operations in processes utilizing libcurl

Monitoring Recommendations

• Enable verbose logging for curl operations to track proxy interactions and connection states
• Deploy network monitoring to identify HTTP proxy CONNECT request failures for non-HTTP protocols
• Implement crash dump analysis procedures to identify double free signatures in affected applications

How to Mitigate CVE-2022-42915

Immediate Actions Required

• Upgrade curl to version 7.86.0 or later immediately on all affected systems
• Audit applications and services that use libcurl to identify exposure, particularly those configured to use HTTP proxies
• Consider temporarily disabling HTTP proxy usage for non-HTTP URL schemes until patches are applied
• Prioritize patching systems that handle LDAP, Gopher, or RTMP traffic through HTTP proxies

Patch Information

The curl project has released version 7.86.0 which addresses this vulnerability. Detailed information about the fix is available in the official curl security advisory. Multiple downstream vendors have also released patches:

• Fedora: Security updates available via Fedora Package Announcements
• Gentoo: GLSA 202212-01
• NetApp: Security Advisory ntap-20221209-0010
• Apple: macOS updates via Apple Support Article HT213604 and HT213605

Workarounds

• Avoid using HTTP proxies for non-HTTP URL schemes (dict, gopher, gophers, ldap, ldaps, rtmp, rtmps, telnet) until patching is complete
• Configure direct connections for vulnerable protocol schemes where network architecture permits
• Implement network segmentation to limit exposure of vulnerable curl instances to untrusted proxy servers

# Verify curl version to check if vulnerable
curl --version | head -1
# If version is between 7.77.0 and 7.85.0, upgrade immediately

# Update curl on Debian/Ubuntu systems
sudo apt update && sudo apt install --only-upgrade curl

# Update curl on RHEL/CentOS/Fedora systems
sudo dnf update curl