The curl project released version 8.23.0 on October 14 to fix CVE-2026-92392, a use-after-free in how curl handles HTTP/2 uploads. It is curl’s first High-severity vulnerability since the SOCKS5 heap overflow of October 2023, and a researcher has shown it can lead to code execution.
CVE-2026-92392: A Use-After-Free in HTTP/2 Uploads
The flaw affects curl and libcurl versions 8.12.0 through 8.22.0. The bug has shipped since 8.12.0, released in February 2025, so it was present in the library for well over a year before the fix. curl rates the vulnerability High.
How a Malicious HTTP/2 Server Corrupts Client Memory
A malicious HTTP/2 server receiving an upload of roughly 135KB can stall the transfer by using a zero window, then reset the stream and trigger a retry. That sequence corrupts memory in the client. The server’s certificate must pass the client’s checks for the attack to proceed, which limits it to servers the client already trusts or that hold valid credentials for the host name.
The HackerOne Write-Up That Reached Code Execution
The researcher who reported the flaw built a working code execution demonstration, described in a HackerOne write-up. curl’s assessment of that result is cautious. Exploitation requires exact knowledge of the build and memory layout, and curl expects real attacks to end in a crash rather than in code execution. No attacks using the flaw have been reported.
A Release With 24 CVEs, 23 of Them Low
The 8.23.0 release fixes 24 CVEs in total, 23 of which are rated Low. The one High-severity entry therefore dominates the release’s security profile even though it makes up a small share of the count.
curl shortened its release cycle by two weeks to ship the fix. It also issued updated long-term-support releases for customers with support contracts, so users on supported older branches have a route that does not require moving to 8.23.0.
Workaround: Avoid HTTP/2
Until patched, curl’s guidance is to update or to avoid HTTP/2, either by passing the –http1.1 option or by setting CURLOPT_HTTP_VERSION to HTTP/1.1 in libcurl-based code. Forcing HTTP/1.1 removes the vulnerable code path, because the flaw lives in HTTP/2 upload handling.
Why a Hard-to-Exploit Bug in libcurl Still Matters
libcurl is embedded in a very large number of applications, and that reach is the source of concern about any curl vulnerability. The sources stress that exploitation is difficult: the attacker has to control or impersonate a trusted HTTP/2 server, match the target build and memory layout, and avoid triggering a crash that would end the attempt. Those requirements separate this case from the unauthenticated network flaws that dominated other advisories published the same day.
The distribution of the fix is the more practical issue. Many applications bundle their own copy of libcurl or link to a system copy, and neither updates when the curl project releases a new version. How quickly the 8.23.0 fix reaches applications depends on the maintainers of those products and on operating system vendors, which the sources do not address.
The Significance of a Rare High Rating
curl’s High-severity rating is uncommon. The project’s last High rating dates to the SOCKS5 heap overflow of October 2023, a gap of three years. By curl’s own scoring, the flaw is rare enough that the project changed its release schedule to ship it, an unusual step for a project that normally follows a fixed cadence. That choice suggests the maintainers treated the researcher’s code execution demonstration as meaningful even while expecting crashes in practice.
The 23 Low-severity CVEs in the same release are a reminder of the volume of reports a widely deployed library receives, but the sources give no detail about them beyond their count and rating.
