curl 8.23.0 fixes HTTP/2 upload use-after-free flaw
curl has released version 8.23.0 to address CVE-2026-92392, a High-severity use-after-free in HTTP/2 uploads that affects curl and libcurl versions 8.12.0 through 8.22.0. The vulnerability lets a malicious server receiving an upload corrupt memory in the client, and the researcher who reported it produced a proof of concept demonstrating code execution on the uploading system.
The project shortened its release cycle from eight weeks to six in order to publish the fix on October 14. Version 8.23.0 resolves 24 CVEs in total; curl rates the remaining 23 as Low. This is curl's first High-severity issue since the SOCKS5 heap overflow disclosed in October 2023.
Conditions needed to reach the vulnerable path
The attack originates at the server side, but it requires the client to upload a file of roughly 135KB over HTTP/2 to a server controlled by the attacker. The server certificate must pass the client's validation checks, and the libcurl build must include HTTP/2 support. For HTTPS URLs, libcurl negotiates HTTP/2 by default when the server offers it.
curl stated that practical code execution demands detailed knowledge of the target's curl version, architecture, libc allocator and heap layout. The attacker must also coordinate two parallel transfers and fit a payload into about 23 bytes. Daniel Stenberg, curl's lead developer, said the more likely outcome of an attempted exploit is a crash, which is why the project assigned High rather than Critical severity. No attacks using the flaw had been reported.
How the HTTP/2 retry produces a stale pointer
HTTP/2 can multiplex transfers over one connection, while libcurl represents each transfer through an easy handle. During the vulnerable upload sequence, the server reduces the HTTP/2 window to zero, returns part of a response and resets the stream without closing the connection. curl treats that reset as a reason to retry the transfer.
In the affected cleanup sequence, curl informed the HTTP/2 layer that the transfer had finished before flushing unsent upload bytes onto the same connection. With no transfer registered, the remaining bytes could be interpreted as a new request. The reporter's upload pattern made those bytes resemble request lines, opening a new stream that retained a pointer to the easy handle.
The retry then completes on a new HTTP/1.1 connection and the application frees that handle, while the old HTTP/2 connection still retains its pointer. A subsequent frame on the stale stream can cause libcurl to use freed memory. The technical pattern adds context to HTTP/2 curl upload vulnerability coverage while showing why server-controlled protocol behavior can put upload clients at risk.
The patch, authored by Stefan Eissing in lib/multi.c, is a six-line reordering. It makes the HTTP/2 layer release its references to the handle after the residual upload data has been flushed rather than before.
Upgrade paths and temporary mitigation
Organizations using curl or applications linked with libcurl should move to 8.23.0, or apply the fix commit to a local build. curl also lists fixed maintenance releases: 8.14.3 for the 8.14.x branch, 8.16.2 for 8.16.x and 8.20.2 for 8.20.x. Debian 13 packages are addressed through DSA-6558-1, while Debian 12 does not include the vulnerable code.
Where an immediate update is not possible, curl advises avoiding HTTP/2. Command-line users can request HTTP/1.1 with --http1.1, and applications can set CURLOPT_HTTP_VERSION to CURL_HTTP_VERSION_1_1; curl notes that connection reuse means the setting is a request rather than an absolute guarantee. Teams should identify upload workflows using HTTP/2-capable libcurl builds, apply the supported update, and use the HTTP/1.1 fallback only until patching is complete.