The curl project has released version 8.23.0, closing 24 security holes in a single release, among them CVE-2026-92392, the first flaw it has graded High since October 2023. The bug lets a hostile server corrupt memory in a client uploading over HTTP/2, and a working proof of concept is now public.
What happened
On 14 October 2026 the curl project shipped curl 8.23.0. The headline item is CVE-2026-92392, “HTTP/2 upload Use-After-Free”, which affects the curl command line tool and the libcurl library from 8.12.0 (February 2025) up to and including 8.22.0. It is rated High on the project’s four-level scale; the other 23 fixes are all graded Low.
Lead developer Daniel Stenberg described it as “one of the worst vulnerabilities in curl in a long time”. It was reported through HackerOne on 15 September, and curl’s maintainers verified it the same day. Rather than push out an emergency build, the team shortened the usual eight-week release cycle to six.
The advisory credits “Luna with Claude, Anthropic” with the find and Stefan Eissing with the patch. Stenberg names the reporter as Luna Tong, working with Anthropic’s new OSS Scanner. No attacks using the flaw have been reported, but according to The Hacker News the reporter’s HackerOne write-up, with a reproducible test set-up, went public on release day.
Backported fixes exist for the 8.14.x (8.14.3), 8.16.x (8.16.2) and 8.20.x (8.20.2) branches. Debian has patched Debian 13 under DSA-6558-1; Debian 12 never contained the faulty code.
The technical picture
HTTP/2 multiplexes many transfers over one connection, so libcurl must track several transfer handles at once. The bug sits in that bookkeeping: when a server ends an upload stream in a certain way, curl can keep a stale reference to a handle the application has already freed, and later clean-up code reuses that memory with server-supplied data in it.
Both the advisory and Stenberg’s write-up are clear that turning this into code execution is hard. The attacker must control the server receiving the upload, with a certificate the client trusts, and needs detailed knowledge of the victim’s curl build, architecture and memory allocator, plus favourable timing. Even then the room for a payload is tiny. The curl team’s view is that a crash is the most likely result of a real-world attempt, which is why it graded the bug High rather than Critical.
The fix is a small reordering of clean-up logic in libcurl’s multi-transfer code. The advisory candidly records it as a C mistake that a memory-safe language would probably have avoided.
The Low-rated fixes are worth a glance too. Several deal with credentials or authentication data reaching the wrong place: Negotiate (Kerberos/SPNEGO) credentials sent to a redirected origin, host credentials leaking to an HTTP proxy, a password exposed through CURLINFO_EFFECTIVE_URL, and a public-key pinning bypass when curl is built with wolfSSL. The release also drops SMB and SMBS support entirely.
Why it matters for UK organisations
curl is one of those components that is everywhere and rarely inventoried. It ships with most Linux distributions and macOS, sits inside container base images, and is linked into a long list of commercial and open source software, from backup agents and monitoring tools to firmware on network kit, and printers. The advisory itself warns that libcurl is often used without being advertised. For most UK organisations, the real exposure is the libcurl bundled in products they bought.
The attack direction also matters. This is a client-side bug: the danger comes from your systems uploading data to a server that is malicious or has been compromised. Think of agents pushing logs, backups or telemetry to external endpoints, CI/CD runners and partner API integrations, many of which will negotiate HTTP/2 over HTTPS by default when the server offers it. A supplier whose upload endpoint has been taken over could become the starting point.
The affected range is fairly recent, so long-term support distributions holding back older curl versions may be unaffected, as Debian 12 shows. Container images and appliances built since early 2025 are more likely to fall inside it. For organisations under the Cyber Essentials scheme, curl updates arriving through operating system packages count as security updates in scope of the security update management control, and the High rating puts this on the shorter end of any patching window.
Expert view
I would not treat this as a drop-everything emergency, and the curl team’s frank write-up deserves credit for making that judgement easy. The exploit conditions are demanding, there is no sign of exploitation, and the attacker needs your system to come to them. In my experience, the bugs that cause real pain are the ones in server-side code reachable by anyone on the internet, and this is not one of those.
The harder problem is finding every copy. When we test client estates, the curl binary on the host is usually patched promptly by the distribution, but the libcurl statically linked into a vendor agent or baked into a container image months ago is another matter. Those copies only get fixed when the vendor rebuilds, and many vendors will not publish anything about a High-rated client bug. This is exactly where a software bill of materials (SBOM) and container image scanning earn their keep.
A public proof of concept does change the arithmetic over time: an exploit that is unreliable today may not stay that way. Patching during the next normal cycle, with priority for systems that upload to external parties, is the proportionate response.
What to do now
- Patch the operating system packages first. Apply vendor curl and libcurl updates as they land (Debian 13 already has DSA-6558-1) and track Red Hat, Ubuntu, SUSE and others for their builds. This maps directly to the Cyber Essentials security update management control.
- Rebuild container images. Rebuild on refreshed base images and redeploy, rather than assuming running containers will pick up host fixes. Scan registries for curl or libcurl between 8.12.0 and 8.22.0.
- Find embedded copies. Use SBOMs, software composition analysis and vulnerability scanners to locate statically linked libcurl in third-party agents, appliances and in-house applications. Ask key suppliers whether their products are affected and when fixes will ship.
- Prioritise systems that upload externally. Backup, log shipping, telemetry and CI/CD jobs that send data to outside endpoints over HTTPS should be first in the queue.
- Use the workaround where patching must wait. The curl project’s guidance is to avoid HTTP/2 for affected transfers, for example forcing HTTP/1.1 in the tool or the library configuration, or building libcurl without HTTP/2.
- Review the Low-rated fixes against your use. If you rely on Negotiate authentication through proxies or redirects, wolfSSL key pinning, or SMB transfers (now removed), check the relevant advisories and test before upgrading.
Bottom line
CVE-2026-92392 is a serious bug in one of the most widely deployed pieces of software on the planet, but it is hard to exploit and needs a hostile server on the other end of an upload. Update curl and libcurl in the next routine cycle, rebuild container images, and put most of the effort into finding the copies hidden inside other people’s products.
