BREAKING: Malicious HTTP/2 servers can crash curl during uploads (CVE-2026-92392)

If you run curl or libcurl 8.12.0 through 8.22.0 and upload anything over HTTP/2, a malicious server can make curl keep using memory it already freed. The curl project published CVE-2026-92392 on 2026-10-14, rates it High, and shipped the fix the same day in curl 8.23.0. The reporter showed the bug can be turned into code execution on the machine running curl, but only when a long list of exact conditions line up. The realistic risk is a crash or worse when your script, CI job or app uploads to a server someone else controls.

This post is our operator read of curl's advisory and the fix commit. The HOL Guard evidence pack for CVE-2026-92392 is the source record.

How to fix

Upgrade curl and libcurl to 8.23.0. Then restart anything long-running that loaded the old library.

# distro packages (Debian / Ubuntu)
sudo apt update && sudo apt install --only-upgrade curl libcurl4t64 libcurl3t64-gnutls

# Homebrew
brew update && brew upgrade curl   # once the formula shows 8.23.0

# source build
curl -LO https://curl.se/download/curl-8.23.0.tar.xz

Package names differ by release (older Debian and Ubuntu use libcurl4 and libcurl3-gnutls). The important part is that distros backport the fix instead of jumping to 8.23.0, so on a distro box you are looking for your vendor's patched build, not the upstream number. Debian, for example, fixed trixie in 8.14.1-2+deb13u7 through DSA-6558-1.

curl also lists fixed points on older branches: 8.14.3 for the 8.14.x line, 8.16.2 for 8.16.x and 8.20.2 for 8.20.x. If you cannot upgrade today, curl's own fallback advice is to stop using HTTP/2 for uploads (for the command line tool, --http1.1).

What actually goes wrong

curl is in the middle of an upload. The server stops granting HTTP/2 flow-control window, so part of the body sits in curl's send buffer. The server then sends RST_STREAM with REFUSED_STREAM or HTTP_1_1_REQUIRED, which tells curl to retry. While cleaning up for the retry, curl first tells the connection to forget the transfer, then flushes the leftover upload bytes into that same connection. Because the connection no longer knows these bytes belong to a body, it parses them as a fresh request. If the bytes happen to look like a request line, curl opens a new stream that holds a pointer to the transfer's Curl_easy handle. The application later frees that handle, the connection keeps the pointer, and the next frame the server sends on that stream touches freed memory.

The fix by Stefan Eissing is a 6-line reorder in multi_done() in lib/multi.c: finish the request first, then tell the connection filters to drop their references. curl's advisory calls it "a C mistake (likely to have been avoided had we not been using C)."

The HackerOne report, filed on 2026-09-15 by Luna with Claude (Anthropic), gives the practical trigger: an upload with curl -T of a file larger than about 135 KB that contains a line shaped like word word anything followed by a blank line. Plenty of real files fit that shape. Markdown docs, logs and HTTP captures all do.

Who is not in scope

• curl older than 8.12.0. The bug arrived in 8.12.0. Debian's tracker marks bookworm (7.88.1) "not affected, vulnerable code not present." Ubuntu 24.04 ships 8.5.0 and 22.04 ships 7.81.0, both before the bug. Debian trixie (8.14.1) and Ubuntu 26.04 (8.18.0) are inside the range, so those need the vendor fix.
• Builds without HTTP/2. If HTTP2 is missing from the Features line of curl --version, this code path is not compiled in.
• Transfers that are not uploads. The advisory scopes it to uploads. A plain download does not leave unsent body bytes in the buffer, so it never reaches the broken cleanup.
• Uploads that stay on HTTP/1.1. The trigger is an HTTP/2 stream reset. curl's own workaround C is "Do not use HTTP/2."
• Anyone already on 8.23.0, or on 8.14.3, 8.16.2 or 8.20.2 in those branches.

Who should move first: CI runners and backup jobs that push artifacts with curl or libcurl to third-party endpoints, and services that upload user-chosen files to user-supplied URLs. Those are the setups where the server on the other end might be hostile.

One operator check

curl --version | head -1; curl --version | grep -o 'HTTP2'

If the first line shows 8.12.0 through 8.22.0 and the second prints HTTP2, that binary is exposed. On Debian or Ubuntu, compare dpkg -l 'libcurl*' against your vendor's tracker instead, because the upstream number will not move. Then look past the system package. curl's advisory warns that "libcurl is used by many applications, but not always advertised as such!" Language bindings, desktop apps, container base images and statically linked tools can each carry their own libcurl. On a container image, run the same curl --version inside it, or check the image's SBOM for libcurl.

What this is not

This is not an internet worm, and someone cannot hit your machine just because curl is installed. The attacker has to be the HTTP/2 server you are uploading to. The code execution proof in the advisory needed all of the following at once: the exact curl build and struct layout, the exact CPU architecture, a known libc allocator and heap layout, specific nghttp2 and OpenSSL TLS 1.3 behavior, a pinned CA bundle, two parallel transfers with calibrated timing, a correct libc leak, and a command of about 23 bytes. Outside a setup like that, expect a crash rather than takeover. It is also not known to be exploited: there is no report of attacks in the wild, and it is not on CISA KEV as of 2026-10-14.

Same upgrade fixes the other 20

curl published 21 advisories on 2026-10-14. This is the only High. The other 20 are rated Low, covering things like cookie jar handling, HSTS cache entries, Negotiate credentials on redirects and an SFTP/SCP redirect host check. All 21 are fixed in 8.23.0, so this is one upgrade, not 21 tickets. The full list is on curl's security page.

The details

• CVE: CVE-2026-92392, "HTTP/2 upload Use-After-Free"
• Weakness: CWE-416, use after free
• Severity: High (curl project rating)
• Affected: curl and libcurl 8.12.0 to and including 8.22.0, both the tool and the library
• Fixed: 8.23.0, plus 8.14.3, 8.16.2 and 8.20.2 on their branches
• Introduced in: commit cd9107e0128191b7b5396b9eb81bbd20c2d36755
• Fixed in: commit 8b0744af5b1b631da5b938ca31c3f9895ad5a321
• Reported by: Luna with Claude, Anthropic. Patched by: Stefan Eissing.

References

• curl advisory CVE-2026-92392
• curl advisory JSON (OSV)
• HackerOne report 4030333
• Fix commit 8b0744af
• Debian security tracker
• curl 8.23.0 changelog