A significant flaw in how **curl** handles HTTP/2 uploads has been uncovered, allowing a malicious server to corrupt a client's memory. The researcher who reported the vulnerability successfully demonstrated how this could escalate to remote code execution on the uploading machine. **curl** project developers addressed the issue on October 14 with the release of **curl 8.23.0**. While a successful code execution attack requires exact knowledge of the client's build and memory layout, the project anticipates that most exploitation attempts would result in a crash rather than full compromise. ### Understanding **CVE-2026-92392** The vulnerability, a use-after-free tracked as **CVE-2026-92392**, impacts **curl** and **libcurl** versions 8.12.0 through 8.22.0. This includes both the command-line tool and the widely used library relied upon by numerous other programs for data transfers. **curl** has rated this flaw as High severity, marking it as their first High-severity issue since the **SOCKS5 heap overflow of October 2023**. The project expedited its release cycle by two weeks to deploy the fix. The attack is server-side initiated. For an exploit to occur, the client must upload a file of approximately 135KB over HTTP/2 to an attacker-controlled server, and the server's certificate must pass the client's validation checks. **libcurl** negotiates HTTP/2 by default for `https://` URLs when the server supports it, provided the library was built with HTTP/2 capabilities. This flaw has been present in every **curl** release since 8.12.0 in February 2025. There are no reports of in-the-wild attacks leveraging this vulnerability. The reporter's **HackerOne** write-up, which includes a malicious server script and a **Docker** container demonstrating the code execution, was made public on October 14 alongside the official advisory. ### Immediate Actions and Mitigation Strategies IT security professionals and privacy-conscious users should prioritize upgrading to **curl 8.23.0** or applying the [fix commit](https://github.com/curl/curl/commit/8b0744af5b1b631da5b938ca31c3f9895ad5a321) to local builds. The **curl** project's [machine-readable advisory](https://curl.se/docs/CVE-2026-92392.json) also lists fixed versions across older branches. Updated **Rock-solid curl** releases, their long-term-support line, are being shipped in parallel with 8.23.0: * **curl** and **libcurl** 8.12.0 through 8.22.0: Upgrade to 8.23.0 * 8.14.x branch: 8.14.3 * 8.16.x branch: 8.16.2 * 8.20.x branch: 8.20.2 * **Debian 13 (trixie)**: 8.14.1-2+deb13u7 via DSA-6558-1, as per [Debian's tracker](https://security-tracker.debian.org/tracker/CVE-2026-92392). **Debian 12 (bookworm)** is not affected. The 8.23.0 release addresses a total of 24 CVEs, with the remaining 23 rated as Low severity. If an immediate update is not feasible, **curl** advises against using HTTP/2. The `--http1.1` option can be used with the command-line tool, and applications can set `CURLOPT_HTTP_VERSION` to `CURL_HTTP_VERSION_1_1`. It's important to note that this is a request, and an existing connection on another version might be reused. Alternatively, building **libcurl** without HTTP/2 support (a [build option](https://curl.se/docs/manpage.html#--http2)) will prevent it from negotiating HTTP/2, thereby eliminating the vulnerable upload path. ### The Mechanics of the Attack **Daniel Stenberg**, **curl**'s lead developer, [detailed the bug](https://daniel.haxx.se/blog/2026/10/14/a-uaf-turned-rce/) in a post published with the release, complementing the public report that outlines the code path. HTTP/2 manages multiple transfers over a single connection, with **libcurl** tracking each transfer via an 'easy handle' object. During an upload, the attacker's server can stall the transfer by setting the HTTP/2 window to zero, returning a partial response, and then resetting the stream while keeping the connection open. **curl** interprets this reset as a trigger to retry the operation.  In the cleanup phase, **curl** first signals the HTTP/2 layer that the transfer is complete, then flushes any remaining unsent upload data into the same connection. With no transfer registered, these leftover bytes are mistakenly read as a new request. The reporter's crafted pattern within the uploaded file makes them appear as valid request lines. This process opens a new stream that inadvertently stores a pointer to the now-finished easy handle. The retry then completes over a new HTTP/1.1 connection, and the application proceeds to free the original easy handle. Critically, the old HTTP/2 connection still retains the pointer to this freed memory and attempts to use it when the server sends a frame on that stream, potentially as the program exits. In the reporter's proof-of-concept exploit, data sent by the server lands in the memory previously occupied by the freed handle. An outgoing request can leak local addresses, which the server can use to bypass Address Space Layout Randomization (**ASLR**). A function pointer within that memory is then overwritten with attacker-controlled bytes, which **curl** subsequently calls. Achieving code execution necessitates precise knowledge of the target's **curl** version, architecture, **libc** allocator, and heap layout. It also requires careful timing of two parallel transfers and fitting the payload into approximately 23 bytes. **Stenberg** noted that the most probable outcome of an attack attempt is a crash, rather than successful code execution, which influenced the High rather than Critical severity rating. **curl** utilizes a four-level severity scale and does not publish **CVSS** scores. As of October 14, the **National Vulnerability Database** had not yet analyzed the record. The fix, a concise six-line reordering in `lib/multi.c` by **Stefan Eissing**, ensures that the HTTP/2 layer relinquishes its references to the handle only after all leftover upload data has been flushed, preventing the use-after-free condition. ### AI-Assisted Vulnerability Discovery The report reached **curl** via **HackerOne** on September 15, with the security team confirming it within hours. On [October 7](https://daniel.haxx.se/blog/2026/10/07/twenty-two-pending-curl-vulnerabilities/), the project pre-announced a High-severity fix for the upcoming release, shortening its development cycle from eight to six weeks. **curl** credits the discovery to "**Luna with Claude, Anthropic**." **Stenberg** identified the reporter as **Luna Tong** of **Anthropic**, presuming the company's AI models were involved through their new **OSS Scanner**. **Anthropic** launched its **OSS Scanner** on October 8 as an opt-in service designed to scan enrolled open-source projects using its AI models, emailing results [without human review](https://red.anthropic.com/oss-scanner). Each report includes a reproducer and, where available, a candidate patch. The **curl** report was submitted three weeks prior to this public launch. **Anthropic**'s [launch post](https://www.anthropic.com/research/launching-opt-in-vuln-finding-service-for-open-source) quoted **Stenberg** stating the scanner had unearthed "one of the worst curl vulnerabilities reported in the last few years," without specifying which one. This finding comes despite **Stenberg**'s previous comments in [July 2025](https://daniel.haxx.se/blog/2025/07/14/death-by-a-thousand-slops/) that approximately a fifth of **curl**'s security submissions that year were what he termed "AI slop," with only about one in twenty proving genuine. While **curl** has been moving towards reducing internal pointers in favor of identifiers, which helps mitigate such bugs, the project acknowledges that this is not a complete guarantee against use-after-free vulnerabilities. The project noted that a memory-safe language would likely have prevented this specific bug, but there are no current plans to rewrite **curl** in such a language.