curl 8.23.0 fixes high-severity HTTP/2 upload flaw that can lead to code execution

The curl project released version 8.23.0 to fix CVE-2026-92392, a use-after-free in HTTP/2 uploads affecting curl and libcurl 8.12.0 through 8.22.0.

curl 8.23.0 fixes high-severity HTTP/2 upload flaw that can lead to code execution

At a glance

  • CVE-2026-92392 affects curl and libcurl 8.12.0 through 8.22.0 and is fixed in 8.23.0, released October 14.
  • A malicious HTTP/2 server can trigger a use-after-free during an upload; curl says the most likely outcome is a crash.
  • Backported fixes exist in 8.14.3, 8.16.2 and 8.20.2; disabling HTTP/2 is the documented workaround.
  • It is the first high-severity curl flaw since October 2023, according to The Hacker News.

The curl project released curl 8.23.0 on October 14, 2026, fixing CVE-2026-92392, a high-severity use-after-free in the way curl and libcurl handle HTTP/2 uploads. According to the project's advisory, the bug affects versions 8.12.0 through 8.22.0, including the command-line tool, and could in theory be turned into remote code execution when a client uploads data to a malicious server. Because libcurl is embedded in a vast number of operating systems, devices and applications, the fix is likely to ripple through many downstream updates.

What happened

The curl advisory says the flaw was reported on September 15, 2026, and credits "Luna with Claude, Anthropic" as the reporter, with Stefan Eissing writing the patch. The Hacker News reports that the project shortened its release cycle by two weeks to ship the fix and had pre-announced a high-severity fix on October 7. Version 8.23.0 fixes 24 CVEs in total, the other 23 rated low, according to the same report. The Hacker News adds that this is the first high-severity curl vulnerability since the SOCKS5 heap overflow disclosed in October 2023.

Technical details

According to the advisory, curl mishandles an HTTP/2 RST_STREAM frame with the reason HTTP_1_1_REQUIRED or REFUSED_STREAM sent by the server during an upload, which leads to a use-after-free of an internal struct Curl_easy object. The Hacker News explains that curl treats the reset as a reason to retry and, during cleanup, flushes leftover upload data into the connection after the transfer has been deregistered, leaving a stale reference to a freed handle. The fix is a short reordering in lib/multi.c.

Exploitation is not trivial. The Hacker News, citing curl's advisory, says the client must upload roughly 135KB over HTTP/2 to an attacker-controlled server whose certificate passes the client's checks, and that code execution would require knowing the exact curl version, architecture, allocator and heap layout. Lead developer Daniel Stenberg said the most likely outcome of an attempted attack "is rather just a crash." A reproducer and a demonstration of code execution in a controlled environment were published alongside the advisory, according to The Hacker News. No in-the-wild exploitation has been reported.

Who is affected

Any application or system that uses curl or libcurl 8.12.0 through 8.22.0 built with HTTP/2 support and uploads data over HTTPS may be exposed, since libcurl negotiates HTTP/2 by default when a server offers it. The Hacker News notes that Debian 12 does not carry the vulnerable code, while Debian 13 received a fixed package through DSA-6558-1.

What to do

  • Upgrade to curl 8.23.0, or to the backported releases 8.14.3, 8.16.2 or 8.20.2 on older branches.
  • Track updates from operating system vendors and software suppliers that bundle libcurl.
  • If an immediate upgrade is not possible, the advisory recommends avoiding HTTP/2, for example with the --http1.1 option or by setting CURLOPT_HTTP_VERSION to CURL_HTTP_VERSION_1_1 in applications.

Related CVEs

Sources

This story is based on the sources listed above. Always check the vendor’s official advisory before acting on critical systems.