A curl bug let a hostile server hijack the uploader, and someone proved it

Key points

• A memory-handling flaw in curl, tracked as CVE-2026-92392, lets a malicious server attack the machine uploading to it over HTTP/2, and the researcher who found it built working code execution on the client.
• The curl project shipped the fix in version 8.23.0 on October 14, 2026.
• The bug was introduced in curl 8.12.0, so older long-term releases including Debian bookworm's 7.88.1 are not affected.
• A real-world attack needs precise knowledge of the target's build and memory layout, and curl's own maintainers say most attempts will simply crash the client.

Curl is the small program that quietly moves data around the internet. It sits inside routers, phones, backup scripts and more or less every Linux server on the planet. When a developer says their app "makes an HTTP request," there's a good chance curl, or its sister library libcurl, is doing the work.

The flaw sits in curl's HTTP/2 upload code. HTTP/2 is the modern version of the protocol browsers use to talk to websites. A server on the receiving end of an upload can trick the client, the machine doing the sending, into reusing a chunk of memory it's already thrown away. That's a use-after-free, a classic programming error where a program keeps writing to memory that has been handed back to the system.

The researcher who reported it went further than a proof-of-concept crash. They turned the memory corruption into remote code execution on the uploading machine, meaning a hostile server could run its own instructions on a client that merely tried to send it a file. We've covered use-after-free bugs eight times since June, but this is the first one we've seen walked all the way to client-side code execution over HTTP/2, a protocol we tracked getting weaponised for traffic concealment in our August Kimwolf v7 piece.

How bad is this in practice?

Bad in theory, narrow in practice. To actually hijack a client the attacker needs to know how that specific curl binary was built: which compiler it used, roughly where things sit in memory. Get it wrong and curl crashes, which is noisy and achieves nothing. The curl project expects that most exploitation attempts in the wild will end in a crashed process, not a shell.

That doesn't make it harmless. Anywhere curl is pointed at an untrusted server over HTTP/2, from a build pipeline pulling artifacts to a scraper collecting data, the risk is real. Automated systems that retry on crash are the obvious soft target.

Who needs to patch, and who can relax?

Update to 8.23.0 if you're running curl 8.12.0 or later. Anything older, including the 7.x line that still ships inside long-term Linux releases, didn't contain the vulnerable code and isn't affected.

For ordinary users this is a background update: your package manager will pull in the fix on its next run. The people who need to move faster are the ones shipping curl inside their own products, container base images, embedded devices, CI runners. First reported by The Hacker News, this is the kind of bug that lingers in forgotten builds for years.

My read: the exploit demo is the story here. Curl memory bugs show up every few months and most get a shrug. One that a researcher walked all the way to code execution on the client, in a protocol that's now the default for a lot of traffic, is worth the emergency package rebuild. Watch for vendors who quietly skip this one because "it only affects uploads."