Curl's HIGH-Rated CVE-2026-92392 Needs a 135 KB Upload and a 23-Byte Payload Area to Reach Code Execution

An attacker who runs an HTTP/2 server with a valid certificate can crash a curl client during an upload, and under a narrow set of conditions can run code in it. That is CVE-2026-92392, a use-after-free in curl 8.12.0 through 8.22.0, fixed in curl 8.23.0 on Oct. 14. The project grades it HIGH, one of one in a release that carried 24 advisories.

The advisory classes it as CWE-416. During an upload, curl mishandles an HTTP/2 RST_STREAM frame from the server carrying the reason HTTP_1_1_REQUIRED or REFUSED_STREAM, which frees a struct Curl_easy object that is still referenced. The command-line tool is affected as well as libcurl.

What an attacker needs

Daniel Stenberg's write-up, "A UAF turned RCE", lists the preconditions. The project's own conclusion is that "we deem it extremely difficult to meet these requirements in the wild."

Condition	Value in the write-up
Victim action	Uploads to a malicious server
Server certificate	Valid
Upload size	About 135 KB
Attacker knowledge	curl architecture, heap layout, build details
Writable payload area	About 23 bytes
Required behaviour	Specific nghttp2 and OpenSSL TLS 1.3 session-ticket allocations

The mechanism, per the post: the server pauses the upload by zeroing the window size, sends a partial response and resets the stream. curl cleans up the transfer but keeps a dangling pointer. The application frees the handle, and when libcurl later cleans up the multi handle it writes downloaded data into the freed memory, which can reach a function pointer. The process also leaks local address information that helps defeat ASLR.

The score here is a label rather than a number. The post says curl "never provide[s] CVSS" for its vulnerabilities, so HIGH is a project judgement. It adds that "the most likely outcome of an attempted attack is rather just a crash" and "the chance for a successful attack is slim." The rating is defensible for a memory-corruption bug in a widely linked library, but the preconditions put exploitation well beyond opportunistic scanning. No exploitation in the wild is reported in any source consulted.

Timeline and affected versions

• Sept. 15: the report arrives. The curl security team confirms it "just hours after" submission.
• Oct. 7: Stenberg announces 22 pending vulnerabilities including one HIGH, and a release shortened from eight weeks to six.
• Oct. 14: curl 8.23.0 ships with the advisory.

The advisory credits "Luna with Claude, Anthropic," and Stenberg's post names the reporter as Luna Tong at Anthropic, using Anthropic's OSS Scanner. Stefan Eissing is credited with the patch.

Affected: curl 8.12.0 through 8.22.0. Not affected: anything before 8.12.0, 8.23.0 or later, and the 8.20, 8.16 and 8.14 branches at 8.20.2, 8.16.2 and 8.14.3 or later.

What to do

Upgrade to 8.23.0, or apply the fix commit to a local build. The advisory's workaround is blunt: "Do not use HTTP/2." Applications that upload to servers they do not control, and that link a vulnerable libcurl, should move first. Distribution packages may carry a backport under an older version string, so check the vendor's advisory rather than the version alone.

Separately, AI-assisted bug hunting is also the subject of Cloudflare's security-audit skill. For how the project is changing the way it handles lower-severity reports, see curl's move to public GitHub issues.