curl 8.23.0 fixes 24 CVEs, 20 of them found with AI tooling

The curl project released curl 8.23.0 on October 14, 2026, with fixes for 24 security vulnerabilities. One of them, CVE-2026-92392, the project grades HIGH: a use-after-free during HTTP/2 uploads that the project’s advisory says “has been proven to be possible to convert into a Remote Code Execution”. The report reached curl on September 15, carries the credit “Luna with Claude, Anthropic”, and came through OSS Scanner, an opt-in vulnerability-finding service, at no cost to the project, that Anthropic announced on October 8.

The gap between the two dates is in the announcement: Anthropic had “spent the last several weeks validating this pipeline with dozens of open source projects” before the launch, and the same announcement quotes Stenberg on what the scanner found in curl. Daniel Stenberg, curl’s maintainer, writes that the security team confirmed the bug “just hours after it was submitted” and that the team ended up “shortening the release cycle with two weeks. Down from eight to six weeks from the previous release.” In the release post he doesn’t list the 24: “So many that I decided to not list them individually here.”

We read the 24 advisories for this news story and counted the credits. By our count, 18 go to Aisle Research, two to “Luna with Claude, Anthropic” and four to individual reporters. We also ran curl --version in seven official Docker images and asked seven distribution repositories which curl they install, because the HIGH bug sits behind version numbers that look the same before and after the fix.

The HIGH one is an HTTP/2 upload use-after-free that can run code

The advisory’s one-sentence description: “During an upload, curl mishandles HTTP/2 RST_STREAM received from the server (with reason HTTP_1_1_REQUIRED or REFUSED_STREAM) leading to a use after free of a struct Curl_easy object.”

Stenberg’s post walks through it. An application uploads over HTTP/2, which libcurl negotiates by default “when a HTTPS:// URLs is used and the server agrees”. The server “pauses the send by zeroing the HTTP/2 window size, returns a piece of the response and then it resets the stream”, and curl “accidentally leaves a lingering pointer to the involved easy handle”.

When the application frees that handle and cleans up the multi handle, libcurl “manages to download data from the server that ends up in the very same memory previously used for the easy handle”.

Along the way it “sends off a request that leaks internal client details, which includes information about local addresses”, the clue a server needs to get past address space layout randomization. Then libcurl “uses a function pointer that now has been modified by data just downloaded from the server, and then it runs remote code.” One reader on Lobsters, looking at the post’s diagram, still asked “maybe overwriting a function pointer?”; that sentence of the post is the answer the diagram doesn’t give.

The conditions keep it at HIGH

The conditions are why the grade is HIGH and not CRITICAL. A victim has to upload to a malicious server whose certificate is valid; the upload “needs to be roughly the right size (~135KB)”; the attacker needs curl’s architecture and a sequence of allocations that “differs between Linux distros, libc versions/flavors, TLS certificate bundles, libcurl using applications and more”; the payload area is “around 23 bytes”. “The most likely outcome of an attempted attack is rather just a crash,” Stenberg writes. “We estimate that the chance for a successful attack is slim.”

A post of October 7 announcing the early release says how rare that grade is: the project had “only published two CVEs with severity HIGH since 2021”, the most recent CVE-2023-38545.

Affected from 8.12.0 to 8.22.0; curl 8.23.0 is one of three ways out

Affected versions run from 8.12.0, released on February 5, 2025, through 8.22.0. The commit the advisory names as the origin dates from January 21, 2025, “cfilters: kill connection filter events attach+detach”. Stefan Eissing’s fix, from October 12, 2026, has the title “multi: adjust the cleanup order in multi_done”. It moves six lines in one file, so that connection filters “give up any references to data” before libcurl detaches the connection.

The advisory lists three options: upgrade to curl 8.23.0, apply the patch, or “Do not use HTTP/2”. It also names the 8.14.x, 8.16.x and 8.20.x branches as fixed from 8.14.3, 8.16.2 and 8.20.2.

Two things are not public in the way the rest is. The project “never provide[s] CVSS” scores, and the NVD record for the CVE, published the same day, had no score when we read it on October 15. What Stenberg calls the “original report”, with “the full reproducible Docker image”, is on HackerOne, and that page loads only through a script we could not read.

Aisle Research holds 18 of the credits and “Luna with Claude” two

The security page lists the 24, numbered 216 to 239 and all published on October 14. By our count, one is HIGH and 23 are Low, and seven carry the project’s “C mistake” label, “likely to have been avoided had we not been using C”.

The “Reported-by” lines concentrate, as the figure shows.

Aisle Research has 18: ten credited to Stanislav Fort and eight to Joshua Rogers. Aisle’s post gives the same number, “18 of them, or 75% of the total”, and puts its twelve-month total in curl at 35 CVEs. Stenberg’s post of the same day says Aisle engineers spent the last year “pointing their AI powered tooling at the curl source code” and that Aisle “has found more CVEs in curl than any other group or individual ever did before”. Its audit report now sits on curl’s site as the project’s fifth external audit.

Anthropic’s “Luna with Claude” has two. Besides the HIGH one, CVE-2026-107928 is an information leak when uploading over WebSockets with the GnuTLS backend, graded Low, reported on October 9. The other four go one each to Maksim Hayder, Axel Mierczuk, Bobbeh Rhino and Muhamad Arga Reksapati.

A week in August when Claude Mythos found nothing new in curl

Two posts by Stenberg on Mastodon, which Aisle links, put dates around that. On August 24 he wrote, about Claude Mythos, Anthropic’s model, and two other scanners: “Mythos says it can’t find any more. Zeropath finds no vulnerabilities. Codex security shows an empty list.” In a reply two minutes later: “I’m under no illusion that the last vulnerability has been found. It just might be that the easy ones are picked now.” The next day: “Mythos: 0 Aisle: 29”.

The replies narrow what the zero means. Stanislav Fort of Aisle wrote that Stenberg “was talking about the new findings for the upcoming release, which came after the 1 low severity Mythos CVE + the 6 AISLE CVEs”, and Stenberg confirmed: “correct. These numbers are for analyses done this week.” Asked what Aisle runs, he answered that “Aisle is mostly about building harnesses around existing models. But I’m not the expert, I just see the results of their tooling”. The posts don’t say who ran Mythos that week, or how.

Three weeks after the zero, on September 15, the OSS Scanner report of the HIGH bug arrived; Anthropic’s FAQ says the service applies “additional token-hungry and experimental harnesses to find even deeper bugs”. By our reading, that is as far as the sources go: a model line that found nothing new in one week in August, and a pipeline built around the same models that found the worst bug in years three weeks later.

SMB support is gone, and the project reports a faster curl

The rest of the release, by the release post: SMB and SMBS support “is gone”, 281 bugfixes, 476 commits. Performance work the project reports includes base64 encoding “more than twice as fast” and the easy handle shrunk from 4256 to 3064 bytes.

OSS Scanner is a pull request, a Dockerfile and an inbox for unreviewed reports

Anthropic’s announcement of October 8 describes OSS Scanner as “an opt-in vulnerability scanner for the open-source ecosystem”, at no cost, run by Claude models it calls “our strongest models (including Claude Mythos)”. Anthropic states the trade-off up front: the outputs “will be fully model-generated, without human review or triage”, so “it is possible reports will be incorrect or invalid”.

The numbers Anthropic gives for the six months before the launch: “over 29,000 candidate vulnerabilities”, of which it could “manually review and triage approximately 6,000”, and “nearly 5,000 reports” sent unvalidated to maintainers who asked for everything. To test the scanner, it had its penetration testers check 97 critical and high findings across 48 projects: 85, or 88%, “met the bar for our CVD process”, 11 were real but duplicates, one was a false positive. The post quotes Stenberg: OSS Scanner “has helped us find multiple issues in curl worthy of addressing, including one of the worst curl vulnerabilities reported in the last few years.”

Enrolling, and what arrives

Enrolling is a pull request to the anthropics/oss-scanner repository that adds projects/<name>/project.yaml with two required fields, repo and primary_contact. It also takes a Dockerfile that builds the project with every dependency, because, as the FAQ puts it, “The Dockerfile itself is built with network access; everything after it runs without.” The README warns that the addresses in that file are public. An optional threat_model.md tells the scanner how the project rates severity and what is out of scope.

What arrives is email, “each with a reproducer and a proposed patch where available”. No 90-day clock applies: Anthropic “will not place any form of 90-day coordinated disclosure period on these unvalidated findings” and will not make them public; a finding later validated by a human enters its usual disclosure process.

Eligibility follows “a similar set of criteria that OSS-Fuzz uses”, projects with “critical impact on infrastructure and user security”, and the FAQ adds that the service “is built for projects that are already able to keep up with verified high/critical vulnerability reports”. A disabled: true line pauses it. The FAQ’s changelog shows an update on October 13 explaining that every sign-up “is reviewed by a human” who confirms the requester is a core maintainer.

The version number alone doesn’t say whether your curl is patched

On October 15, 2026, we ran curl --version in seven official Docker images and asked the package managers of seven distribution images which curl they install today. The table has the result. The status column is our comparison of each package string with the Debian and Ubuntu trackers and, for Alpine and Fedora, with the package sources; the Fedora row’s update version comes from Bodhi, Fedora’s update system, because the run only showed the package installed in the image.

Four Debian 13 images print 8.14.1 either way

The four Debian 13 images print curl 8.14.1 whether they carry the fix or not. Debian’s tracker lists 8.14.1-2+deb13u5 as vulnerable and 8.14.1-2+deb13u7, shipped as DSA-6558-1, as fixed. The trixie repository already serves deb13u7, so an apt-get upgrade inside any of those images gets the fix, and their next rebuild gets it too. Those images as published on October 6 carry deb13u5, and golang:1.25, from August 19, carries deb13u4.

The same holds for eclipse-temurin:21-jdk on Ubuntu 26.04: 8.18.0-1ubuntu2.7 inside, and Ubuntu’s page says fixed in 8.18.0-1ubuntu2.8. Ubuntu 24.04 and 22.04 ship 8.5.0 and 7.81.0, which Ubuntu marks not affected, as does Debian for bookworm’s 7.88.1: “Vulnerable code not present”.

Read the package version, not the upstream one

curl’s advisory names 8.14.3 as the first safe version of the 8.14 branch; that is curl’s numbering, and Debian’s fix lives in a package still called 8.14.1. On Debian and Ubuntu, the package version comes from dpkg:

dpkg-query -W -f='${Package} ${Version}\n' curl libcurl4t64 libcurl4 2>/dev/null

dpkg-query -W -f='${Package} ${Version}\n' curl libcurl4t64 libcurl4 2>/dev/null

It prints one line per package name it knows, with the version empty for one that isn’t installed. On Debian 13 that is libcurl4 with nothing after it, next to libcurl4t64 8.14.1-2+deb13u5; the second string is what you compare with the tracker’s fixed one. Applications bring their own libcurl too; the advisory’s reminder is that “libcurl is used by many applications, but not always advertised as such!”

Alpine and Fedora had no fix on October 15

Alpine and Fedora had not shipped a fix when we looked. Alpine 3.24’s package is 8.22.0-r0, inside the affected range, and the secfixes block of its APKBUILD, the list Alpine keeps of which release fixed which CVE, ends at 8.22.0-r0 and names none of the 24 CVEs of October 14. Fedora 44’s package is 8.18.0, and the fedora:latest image, one of the seven distribution images, carries build 8.18.0-8.

Its newest update, 8.18.0-14, went stable on October 14 by Bodhi, and none of the five most recent updates there mentions CVE-2026-92392.

All seven images with a curl binary report HTTP2 in the output of curl --version. Tested with: Docker 29.7.2 on Ubuntu 24.04.2 (WSL2), October 15, 2026, UTC; this machine’s own curl is 8.5.0.

Where the bug bites, and three ways to close it

By our reading of the advisories and the trackers, the bug needs an upload over HTTP/2 to a server that misbehaves on purpose. That is libcurl sending a request body to a host you don’t control over HTTPS, where HTTP/2 is the default, from a client that still has a build between 8.12.0 and 8.22.0 without a backported fix. A download-only client, or a client talking to your own servers, is outside the trigger Stenberg describes.

Upgrade, rebuild, or force HTTP/1.1

If you can upgrade, curl 8.23.0 or your distribution’s patched package is the fix. In a Dockerfile that means rebuilding on a base image published after the fix or running the package upgrade in the build; for Debian 13 and Ubuntu 26.04 bases the repositories already had it on October 15, for Alpine and Fedora bases they did not.

Without an upgrade path, the advisory’s third option is to turn HTTP/2 off for uploads. The --http1.1 flag does it for the tool, and CURLOPT_HTTP_VERSION set to CURL_HTTP_VERSION_1_1 for libcurl, with the caveat in its documentation that “the HTTP version is a request” and libcurl “might then reuse a connection using an HTTP version you have not asked for”.

If you maintain a project the scanner would take, the decision is whether your project can absorb an inbox of unreviewed, patch-attached reports; the cost of finding out is a project.yaml and a Dockerfile.

The reproducer that Stenberg recommends reading sits on HackerOne, and the only description of it we have is his. No CVSS score exists from the project or, on October 15, from NVD; Alpine and Fedora packages for the 24 CVEs had not appeared by then, and the October 7 post gives no date for the release after 8.23.0. The next things to look for are those two packages and the rebuilds of the Debian 13 language images, which is where most of the 8.14.1 strings in the table come from.

Related posts:

Claude Cowork: Anthropic Introduces an AI Agent That Works Directly With Your Files Claude Opus 5.5 vs GPT-6 Sol and Luna: prices, benchmarks, platforms Claude Sonnet 5.5 vs Opus 5.5: cost per task, where each fits A New DeepSeek Paper Highlights the Growing Push for More Efficient AI Training OpenAI Launches ChatGPT Health: New AI Tool Focused on Healthcare with Reinforced Privacy GPT-6.1 Sol: what changed from GPT-6 Sol and what a task costs