curl 8.23.0 fixes HTTP/2 upload use-after-free (CVE-2026-92392)

The curl project shipped version 8.23.0 on October 14, 2026, closing a use-after-free in the way curl and libcurl handle HTTP/2 uploads. Tracked as CVE-2026-92392, the bug lets a malicious server that receives an upload corrupt the client's memory. The researcher who reported it showed that, under tightly controlled conditions, this can be turned into code execution on the uploading machine.

curl rates the issue High on its own four-level scale, its first High-severity flaw since the SOCKS5 heap overflow of October 2023. The project expects that a real-world attempt would most likely just crash the client rather than achieve code execution.

What happened

• Affected: curl and libcurl 8.12.0 through 8.22.0, so every release since February 2025. Both the command-line tool and the library are affected.
• Attack direction: server to client. The victim has to upload data (roughly 135 KB or more) over HTTP/2 to a server the attacker controls, and that server's TLS certificate must pass the client's checks.
• Precondition: libcurl must be built with HTTP/2 support. When it is, libcurl negotiates HTTP/2 by default for https:// URLs whenever the server offers it.
• Exploitation status: no in-the-wild attacks have been reported. The reporter's HackerOne write-up, including a proof-of-concept server and a Docker reproduction, became public with the advisory.

In short, a hostile server can stall an upload, reset the HTTP/2 stream and trick curl into a retry. That leaves a stale pointer to a freed transfer handle. Turning the stale pointer into code execution requires the attacker to know the exact curl version, architecture, allocator and heap layout, to win a timing race between two parallel transfers, and to fit a payload into about 23 bytes. That difficulty is why curl graded the flaw High rather than Critical. The fix is a small reorder in lib/multi.c, so the HTTP/2 layer now releases its references only after the leftover upload data has been flushed.

curl does not publish CVSS scores. As of October 14 the NVD had not yet analyzed the record, so expect third-party severity ratings to vary.

The issue was reported on September 15 and credited by curl to "Luna with Claude, Anthropic". The curl maintainer says it came through Anthropic's newly launched OSS Scanner service, an AI-assisted bug-finding program for open-source projects. It is a notable data point in the ongoing debate about AI-generated vulnerability reports, which curl's maintainers have previously criticized as mostly noise.

Why it matters

curl and libcurl sit inside an enormous range of software: CI/CD pipelines, backup and sync agents, package managers, firmware updaters, IoT devices and countless applications that embed libcurl for HTTP transfers. Many of these upload data to remote endpoints automatically. Any of them can be exposed if it talks HTTP/2 to a server that turns hostile, whether through compromise, a hijacked domain or a malicious endpoint the client is tricked into using. The most likely impact is a denial of service (crash). Code execution is possible in principle, but it is hard to achieve reliably.

The same release fixes 24 CVEs in total. The remaining 23 are rated Low.

What to do

1. Upgrade to curl/libcurl 8.23.0. If you are pinned to an older branch, use the fixed point releases 8.14.3, 8.16.2 or 8.20.2. Customers with curl support contracts get matching long-term-support builds.
2. Patch the copies you don't see. Inventory statically linked or vendored libcurl in containers, appliances, SDKs and third-party software, and check your SBOMs for affected versions.
3. Linux distributions: apply your vendor's update. On Debian 13 (trixie), the fixed package is 8.14.1-2+deb13u7 (DSA-6558-1). Debian 12 (bookworm) does not ship the vulnerable code.
4. If you cannot update yet, avoid HTTP/2 for uploads. Use --http1.1 on the command line, or set CURLOPT_HTTP_VERSION to CURL_HTTP_VERSION_1_1 in applications. Note that this is a request, and an existing connection on another protocol version may still be reused. Builds compiled without HTTP/2 support cannot reach the vulnerable path.
5. Limit where automated clients upload to. Restrict upload destinations to known, trusted endpoints and keep certificate validation strict.

4Tify's vulnerability assessments flag outdated curl/libcurl components in your exposed stack and software inventory. Talk to us if you want help finding where libcurl is hiding in your environment.

This report is based on coverage first published by The Hacker News and on the curl project's security advisory.