curl fixes high-severity HTTP/2 upload flaw enabling client-side code execution

The curl project released version 8.23.0 on October 14 to fix a high-severity vulnerability that allows malicious servers to corrupt client memory during HTTP/2 uploads. The flaw, tracked as CVE-2026-92392, was discovered by Luna Tong of Anthropic and affects all curl and libcurl versions from 8.12.0 through 8.22.0.

What happened

This vulnerability enables a server controlled by an attacker to trigger remote code execution on the client machine uploading data. The attack requires the client to upload a file of approximately 135KB over HTTP/2 to a malicious server whose certificate passes standard validation checks. While the theoretical impact includes full system compromise, the curl maintainers note that successful exploitation is difficult and likely to result in a crash rather than code execution in most real-world scenarios.

The bug has been present in every curl release since version 8.12.0, which shipped in February 2025. It marks the first high-severity flaw for the project since the SOCKS5 heap overflow in October 2023. In response to the discovery, the curl team shortened its regular eight-week release cycle by two weeks to deliver the patch promptly. No active exploits using this vulnerability have been reported in the wild so far.

The fix addresses a total of 24 CVEs in this release, though the other 23 are rated as low severity. The project also updated its long-term support line, known as Rock-solid curl releases, to align with this security patch. Users on older supported branches should upgrade to specific patched versions: 8.14.3 for the 8.14.x branch, 8.16.2 for 8.16.x, and 8.20.2 for 8.20.x.

How it works

The vulnerability is a use-after-free error rooted in how libcurl manages HTTP/2 transfers. HTTP/2 allows multiple concurrent streams over a single connection, and libcurl tracks each transfer using an object called an easy handle. During an upload, a malicious server can stall the transfer by setting the HTTP/2 window size to zero, returning part of the response, and then resetting the stream while keeping the underlying connection open. Curl interprets this reset as a signal to retry the transfer.

In the cleanup phase of this retry logic, curl previously informed the HTTP/2 layer that the transfer was finished before flushing the remaining unsent upload data. This ordering meant that leftover bytes were written to a connection with no registered transfer. If these bytes resembled HTTP request lines, curl would open a new stream and store a pointer to the easy handle. When the application eventually freed the handle after completing the retry on a new HTTP/1.1 connection, the old connection still held a dangling pointer to that freed memory.

An attacker could then send data on the old stream that lands in the recently freed memory space. By leaking local addresses to bypass address space layout randomization (ASLR), the attacker could overwrite a function pointer in that memory. When curl subsequently called that pointer, it would execute the attacker's code. The fix, a six-line reorder in lib/multi.c by Stefan Eissing, ensures the HTTP/2 layer releases its references to the handle only after any leftover data has been flushed.

Key details

• Affected versions: curl and libcurl 8.12.0 through 8.22.0.
• Fixed versions: Upgrade to 8.23.0, or 8.14.3, 8.16.2, and 8.20.2 for older branches.
• Attack vector: Malicious server receiving an HTTP/2 upload of roughly 135KB.
• Severity: Rated High by the curl project; no CVSS score published.
• Discovery: Reported by Luna Tong of Anthropic via HackerOne on September 15.
• Mitigation: Disable HTTP/2 using --http1.1 or CURLOPT_HTTP_VERSION_1_1 if immediate patching is not possible.

Why it matters

For software engineers and DevOps teams, this incident highlights the risks inherent in widely used infrastructure libraries. Curl is embedded in countless applications, from command-line scripts to complex backend services. Because libcurl negotiates HTTP/2 by default for HTTPS URLs when the server supports it, many applications may be vulnerable without explicit configuration changes. The fact that the vulnerability requires a specific build environment and precise timing to exploit does not negate the risk, especially for targeted attacks against known infrastructure.

The discovery process also signals a shift in how open-source security vulnerabilities are found. The reporter used Anthropic’s OSS Scanner, an AI-driven tool that scans open-source projects and emails results without human review. This raises questions about the future of vulnerability research, as AI models become capable of identifying complex memory corruption bugs that traditional fuzzing might miss. However, it also introduces noise, as maintainers have noted a rise in low-quality AI-generated reports.

What you can do

• Check your current curl version by running curl --version and upgrade to 8.23.0 or a patched branch version immediately.
• If you cannot update right away, force HTTP/1.1 in your applications by setting CURLOPT_HTTP_VERSION to CURL_HTTP_VERSION_1_1.
• Verify if your libcurl build includes HTTP/2 support; if not, you are not vulnerable to this specific flaw.
• Monitor Debian security trackers if you use Debian 13 (trixie), which received patch 8.14.1-2+deb13u7 via DSA-6558-1.
• Review any custom Docker containers or CI/CD pipelines that bundle older versions of curl for file transfers.
• Consider disabling HTTP/2 in internal services where it is not strictly required to reduce the attack surface.