Skip to content
Hacker Posts

curl patches HTTP/2 use-after-free that a PoC turned into RCE

curl 8.23.0 fixes CVE-2026-92392, a use-after-free a malicious HTTP/2 server can trigger during an upload. A PoC reached code execution; curl rates it High.

Published 3 min read
cvecurladvisory

curl shipped 8.23.0 on October 14 to fix CVE-2026-92392, a use-after-free a malicious HTTP/2 server can trigger while the client is uploading. A proof-of-concept turned the bug into client-side code execution, but curl maintainer Daniel Stenberg says the most likely outcome is a crash, and curl rates it High, not Critical. If you ship curl or link libcurl and make HTTP/2 uploads to servers you don't control, update.

The primary source is curl's own advisory, CVE-2026-92392. curl publishes no CVSS score; it sets severity itself.

What the bug is

curl's advisory classifies it as a use-after-free (CWE-416) of a struct Curl_easy object, triggered when a server sends an RST_STREAM during an upload. A hostile server that receives an upload can corrupt the client's memory. The reporter's HackerOne write-up includes a server script and a Docker container described as reproducing code execution — but per the advisory and reporting at The Hacker News, a working attack needs exact knowledge of the target's curl version, architecture, allocator and heap layout, precise timing, and a payload of roughly 23 bytes. That difficulty is why curl rated it High.

The flaw was found by "Luna with Claude, Anthropic" via Anthropic's OSS Scanner, submitted through HackerOne on September 15 and made public with the advisory on October 14. It is the second AI-assisted memory-safety finding to land this week — the curl fix and the Linux kernel's CVE-2026-74580 vhost bug both came out of machine-assisted review.

Affected versions

Per curl's advisory:

  • Affected: curl 8.12.0 up to and including 8.22.0 — the command-line tool and libcurl.
  • Not affected: anything before 8.12.0, and the fixed releases below.

Fixed versions

  • 8.23.0 — the main fix (October 14).
  • 8.14.3, 8.16.2, 8.20.2 — backports on the respective stable branches.
  • Debian 13 (trixie) ships the fix as 8.14.1-2+deb13u7 via DSA-6558-1; Debian 12 (bookworm) does not carry the vulnerable code.

The fix is a six-line reorder in lib/multi.c by Stefan Eissing: commit 8b0744af.

Exploitation status

No source reports exploitation in the wild. The HackerOne PoC (report 4030333) is public, so treat the exploitation bar as "demonstrated, hard to weaponize" rather than "theoretical."

Action checklist

  1. Update to curl/libcurl 8.23.0, or the backport for your branch (8.14.3, 8.16.2, 8.20.2). Rebuild anything that statically links libcurl — the version curl --version prints is not the version your app ships.
  2. If you can't update yet, force HTTP/1.1: pass --http1.1 on the CLI, or set CURLOPT_HTTP_VERSION to CURL_HTTP_VERSION_1_1 in libcurl. A build compiled without HTTP/2 support never reaches the vulnerable path.
  3. Audit container images and language runtimes. curl and libcurl are bundled far beyond the system package; check base images and SDKs that make outbound HTTP/2 calls.

Context

curl's threat model has always put the server in the untrusted position, and HTTP/2's stream state machine keeps producing client-side memory bugs there. The honest read is the one Stenberg gave: the exploitation requirements are steep, the realistic outcome is a crash, and the fix is a small, well-scoped patch you can take today.

Related stories