- The curl project fixed CVE-2026-92392 in curl 8.23.0. The HTTP/2 upload flaw affects 8.12.0 to 8.22.0 and has been shown convertible to remote code execution.
- The exploit needs many exact conditions to line up, and the advisory does not report attacks on real targets. The larger problem is finding every product that embeds curl.
- Ask teams which products embed libcurl, which versions they run, and which upload over HTTPS to outside servers. Patch those first.
The hard part of this curl flaw is not the attack. The hard part is knowing where curl runs in your company. curl is rarely a product you bought. It is a part inside products you bought.
On October 14, 2026, the curl project published an advisory for CVE-2026-92392 and shipped curl 8.23.0 with the fix. The project calls the flaw an "HTTP/2 upload Use-After-Free" and grades it HIGH. It says the flaw has been proven possible to convert into remote code execution. That means a malicious server could run its own commands on the machine making the request.
How the flaw works
A use-after-free is a familiar memory bug. A program frees a piece of memory, but keeps a pointer to it. Later it uses that pointer anyway. If an attacker can control what now sits in that memory, the program can be tricked.
The curl project's blog post walks through the sequence. It starts with an HTTP/2 upload. HTTP/2 lets several transfers share one connection. In libcurl, each transfer has its own "easy handle", an internal record of that transfer.
During the upload, the server pauses the send and returns part of a response. It then resets the stream, which ends that transfer but not the connection. The advisory names two reset reasons: HTTP_1_1_REQUIRED and REFUSED_STREAM.
curl finishes the transfer, but leaves a stray pointer to the easy handle. The application then frees that handle and cleans up the wider "multi handle" that manages transfers. During that cleanup, libcurl follows the stray pointer. Data from the server lands in the memory the freed handle once used.
Two things follow, according to the project. A request leaks internal details about local addresses. Address randomization is meant to hide those, so the attacker needs them. Then libcurl uses a function pointer that the server's data has overwritten, and runs code.
Why the attack is hard to pull off
The advisory lists the conditions a malicious server must meet. They are demanding. The attacker must know the exact curl build and its structure layout, plus the machine architecture. It must know the C library's memory allocator and heap layout. It must account for how nghttp2 and OpenSSL with TLS 1.3 allocate memory, including around session tickets.
Other conditions follow. The attacker must also match the client's pinned CA bundle and other input-dependent memory layouts. Two parallel transfers must keep their timing. The attacker's leak and symbol offsets must be calibrated. The current exploit also limits the command to roughly 23 bytes.
The advisory does not say the flaw has been exploited against real targets. A flaw this demanding is not a reason to ignore it. It is a reason to rank it sensibly. Systems that upload over HTTPS to servers you do not control matter most.
The real exposure is the hidden dependency
The advisory makes a plain point: "libcurl is used by many applications, but not always advertised as such!" It also affects the curl command line tool.
So the question for a leader is not whether the company uses curl. It almost certainly does. The question is which products embed libcurl, which version each carries, and who ships the update. A vendor's appliance or application may bundle its own copy. Your team's patch of the operating system will not reach it.
The lesson here is that patch speed depends on inventory, not on the vulnerability. In our view, teams that can list their software components can answer this question quickly. Teams that cannot may have to ask each vendor in turn.
A C mistake, and a four-week path to a fix
The curl project describes the bug as a "C mistake" that was likely avoided had it not used C. That is the maintainers' own view. It is not a verdict on the language. It is a reminder of the class of memory-safety flaws that C code can produce.
The issue was reported to the project on September 15, 2026. The fix and advisory came out together on October 14, 2026, about four weeks later.
What to ask your team
Ask for a list of every product and internal service that embeds libcurl or calls the curl tool. Ask which of them run versions from 8.12.0 through 8.22.0. Versions before 8.12.0 are not affected.
Check the fixed versions too. Besides 8.23.0, the advisory lists 8.20.2, 8.16.2 and 8.14.3 as not affected in their branches. Anything older in those branches needs an upgrade or a patch.
Then ask which of those systems upload data over HTTPS to servers outside your control. Patch those first. For vendor products, ask in writing which libcurl version they ship and when the update arrives.
An exploit that needs many conditions to line up is a weak reason to wait. The conditions are a puzzle for an attacker. For a defender, the lasting risk is code nobody knew was there.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: curl project (curl.se).
