CVE-2026-92388 in libcurl
Summary
by MITRE • 10/20/2026
When an FTP wildcard `LIST` operation fails, libcurl omits the restoration path meant for successful listings, leaving the write callback set to the internal listing parser and the write callback data pointing directly to the easy handle. Subsequent reuse of this handle triggers an immediate crash, and cloning it via `curl_easy_duphandle()` copies this corrupted state into the duplicate. If the original handle is subsequently freed, executing a transfer on the cloned handle causes a heap use-after-free read against the dangling handle reference; alternatively, reusing the original or cloned handle while changing only `CURLOPT_WRITEDATA` (and omitting `CURLOPT_WRITEFUNCTION`) results in type confusion, forcing the internal parser to interpret incoming server response bytes into memory at the application-supplied write data pointer.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/20/2026
The vulnerability described involves a critical state management flaw within libcurl when handling FTP wildcard LIST operations that fail during execution. Under normal circumstances, after an FTP directory listing is successfully retrieved, libcurl performs cleanup procedures to restore internal callback pointers and data structures to their default or safe states for subsequent reuse of the CURL easy handle. However, when such an operation fails, specifically due to issues with parsing or server response handling associated with wildcard patterns, this restoration logic is bypassed. Consequently, the write callback remains pointed at libcurl's internal listing parser function rather than being reset to a neutral state, and the corresponding write callback data pointer continues to reference the original easy handle structure instead of being cleared or redirected appropriately.
This corrupted internal state creates severe security implications when the affected CURL easy handle is reused for subsequent transfers. Because the write callback remains active with its previous configuration, any incoming data intended for standard transfer operations will be processed by the listing parser logic rather than normal file writing routines. This mismatch between expected behavior and actual execution path leads to immediate crashes in many scenarios due to invalid memory access patterns or type mismatches within the parsing routine. The issue is further exacerbated when developers utilize curl_easy_duphandle() to clone an existing handle, as this function performs a shallow copy of the internal state including these corrupted callback pointers and data references.
The most dangerous aspect of this vulnerability arises from heap use-after-free conditions if the original easy handle containing the corrupted state is freed while a cloned duplicate remains active in memory. When a transfer operation is initiated on the cloned handle, it attempts to access the write callback data pointer which still points to the memory address previously occupied by the now-freed original handle. This results in reading from deallocated heap memory, potentially leading to information disclosure or arbitrary code execution depending on how the freed memory has been reallocated and what content resides there at that moment. Such use-after-free vulnerabilities are particularly dangerous as they can often be exploited for remote code execution with minimal constraints if an attacker can influence the contents of the freed memory region through controlled network inputs or application behavior.
Additionally, even without handle duplication or freeing, reusing a corrupted handle while modifying only CURLOPT_WRITEDATA presents significant risks related to type confusion and arbitrary write primitives. If developers change the write data pointer but fail to explicitly reset CURLOPT_WRITEFUNCTION back to NULL or their own custom function, libcurl continues using its internal listing parser as the callback handler. This forces the parser to interpret raw server response bytes according to FTP directory listing formats rather than standard file content structures. Since the destination memory address is now controlled by the application via CURLOP_WRITEDATA but interpreted through a rigid parsing logic designed for specific text-based responses, this can lead to out-of-bounds writes or corruption of adjacent heap metadata if the parsed data exceeds expected bounds or contains unexpected binary sequences that trigger malformed pointer calculations within the parser.
From an industry standard perspective, this vulnerability aligns with CWE-416 Use After Free and CWE-787 Out-of-Bounds Write due to improper validation of internal state during resource reuse. The exploitation technique involving callback hijacking through incomplete cleanup also relates to CWE-937 Use of Broken or Insecure Algorithm in the context of state machine management, although more accurately it represents a failure in proper object lifecycle management akin to CWE-672 Operation on Resource after Expiration or Release. In terms of MITRE ATT&CK mapping, this vulnerability facilitates initial access and privilege escalation vectors by allowing attackers to achieve arbitrary read/write capabilities through crafted FTP responses that trigger the flawed state transitions during wildcard listing operations.
Mitigation strategies must focus on ensuring robust cleanup procedures regardless of operation success or failure status within libcurl's FTP module developers should verify that all callback pointers and associated data structures are explicitly reset to safe defaults whenever a transfer completes, fails, or is aborted. For application developers utilizing libcurl, it is crucial to avoid reusing CURL easy handles across different types of operations without explicit verification of their internal state integrity. When cloning handles via curl_easy_duphandle(), extra caution should be exercised as the clone inherits all internal configurations including any potential corruption from the source handle. Implementing strict validation checks before each transfer initiation and ensuring that CURLOPT_WRITEFUNCTION is explicitly set to NULL or a custom handler when not performing directory listings can prevent accidental invocation of inappropriate parsing logic against arbitrary memory locations.