curl's first High flaw in 1,099 days was in 13 releases; curl lists eight conditions for code execution

616 days, 13 releases and one High: what is fixed on the record

curl's release table puts the first affected release, 8.12.0, on 5 February 2025 and the fix, 8.23.0, on 14 October 2026. That is 616 days, or 20 months and 9 days (derived). curl's advisory for CVE-2026-92392 lists 13 releases in that span as affected, 8.12.0 to 8.22.0, a count that matches the release table. curl rates the flaw High on its own four-level scale. It is the project's first High since the SOCKS5 heap overflow it published on 11 October 2023, 1,099 days earlier (derived), with 81 advisories in between that curl rated Low or Medium (derived from curl's vulnerability table).

That is what the record fixes. What it does not establish is the part a decision rests on. It does not say how many deployed programs upload over HTTP/2 to a server that someone other than their operator chooses. It does not say how reliably the code-execution route works outside the reporter's own setup: curl lists eight conditions for it, and its lead developer wrote that the most likely outcome of an attempted attack is a crash. It does not say which embedded devices ship an affected libcurl and cannot be updated. And it does not say that anyone is using the flaw. The Hacker News reports that no source describes attacks. CISA's Known Exploited Vulnerabilities catalogue (version 2026.10.13, 1,741 entries) did not list the CVE at 19:30 BST on 14 October, and the FIRST EPSS model gave it 0.226 per cent that day, a prediction and not an observation.

This briefing reads curl's own pages: the advisory and its machine-readable JSON, the 8.23.0 changelog, the release table, the vulnerability table, the disclosure policy and the release procedure; the project's mailing-list posts of 14 October and its lead developer's post of the same day; the CVE record and the National Vulnerability Database (NVD) record; and the Debian, Ubuntu, Red Hat, Alpine and Fedora pages. They were read from 19:05 BST on Wednesday 14 October 2026. Tracker states are time-stamped because several change within hours. The Hacker News article was read in full in a browser and is used as a secondary source. The reporter's public write-up exists: curl's advisory links it as the original report, and the release post points to it and to a reproducible container. This briefing does not link to it, describe it or reproduce anything from it, and did not read it. It is defender level only.

What curl states, and what it leaves out

What the primary pages state about CVE-2026-92392, and what they do not. Read 14 October 2026 from 19:05 BST; the Hacker News is the only source for the rows marked as such.

Topic	Stated on the record	Not stated
The flaw	During an upload, curl mishandles an HTTP/2 stream reset sent by the server, leading to a use after free of an internal transfer object (CVE text). CWE-416. curl calls it a C mistake that likely would have been avoided in another language.	How it went unfound for 13 releases.
Affected	curl 8.12.0 to and including 8.22.0, the command line tool and libcurl. Not affected below 8.12.0 or from 8.23.0.	How many products embed an affected build.
Severity	curl: High, and no CVSS by policy. Red Hat: Important, CVSS 8.1, marked preliminary. Ubuntu: High, citing upstream. NVD: status Received, no score at 19:30 BST.	Any CVSS score from the CNA (curl) or NVD.
Code execution	The advisory says conversion to remote code execution has been proven possible if a set of specific criteria are met by the malicious server, and lists eight.	How many real systems meet all eight.
Likely outcome	curl's lead developer: the most likely outcome of an attempted attack is a crash, and the chance of success is slim.	What a crash costs a service that uploads for a living.
Exploitation	Hacker News: no source reports attacks. CISA KEV: not listed at 19:30 BST. EPSS: 0.226 per cent (a model).	Whether curl has seen attempts. curl says nothing either way.
Fix	Upgrade to 8.23.0, apply the patch, or do not use HTTP/2. Fixed builds of three older branches (8.14.3, 8.16.2, 8.20.2) exist for support customers.	Public fixed builds for those three branches.
Timeline	Reported to curl on 15 September 2026. CVE reserved 16 September. Fix commit authored 12 October. Release and advisory 14 October.	Any pre-announcement. Hacker News says one went out on 7 October; none appears in the public archives read.

Eight conditions for code execution, and what High means here

The advisory says the use-after-free has been "proven to be possible to convert into a Remote Code Execution" if a set of specific criteria are met by the malicious server, and it lists eight. The table paraphrases them. The third column is this briefing's reading of what each depends on, not curl's wording.

The eight conditions in the Info section of curl's advisory, paraphrased and grouped. Column three is this briefing's reading. Nothing here is a step.

#	What curl says the malicious server needs	What it depends on
1	The exact curl version and the layout of its internal objects, used to derive offsets.	The build you run.
2	Exact architecture details of the running curl.	The processor and platform.
3	A known, compatible libc allocator build and heap layout.	The operating system image.
4	nghttp2 and OpenSSL TLS 1.3 behaviour, including allocation effects around session tickets.	The library versions linked.
5	A pinned CA bundle and other input-dependent allocation geometry.	What the application loads and sends.
6	Two parallel transfers whose scheduling and timing must hold.	How the application schedules transfers.
7	Correctly calibrated libc leak and symbol offsets.	Per-build calibration.
8	The exploit's current short-command constraint, about 23 bytes.	The state of the exploit, not of the bug.

curl's lead developer wrote that the project deems it "extremely difficult to meet these requirements in the wild", which is why it graded the flaw High and not Critical, and that "The most likely outcome of an attempted attack is rather just a crash." He also wrote that the chance of a successful attack is slim. He opened the same post by calling it "one of the worst vulnerabilities in curl in a long time".

One inference, labelled as one. Conditions that depend on the exact build protect against an attacker who has not seen your build. They do not protect a stock build that runs identically on thousands of hosts, which is the build an attacker is most likely to have studied. curl does not say this. Our earlier briefing on a Ghostscript flaw (read it here) recorded a security firm's finding that two exploit files failed 10,240 times on other builds and worked on the build they were made for: the same dependence on the exact build, read the other way.

To scale: 13 releases, a report 29 days before the fix, and a cycle cut by two weeks

Drawn to scale from curl's own dates, the figure shows what the headline hides. The oldest affected release had been out 616 days when the fix shipped, and the newest, 8.22.0, had been out 42. The report reached curl 13 days after 8.22.0 shipped and 29 days before the fix (derived).

curl's release procedure says it normally releases every 8 weeks, 56 days. A capture of that page dated 6 October 2026 listed 28 October as the next date, 56 days after 8.22.0. 8.23.0 shipped on 14 October, 42 days after 8.22.0, 14 days early (derived). The live page now lists 14 October and then 9 December, 56 days later. The release candidate that ships seven days before a release appeared on 7 October, which fits 14 October (derived). curl's lead developer wrote that the team confirmed the report within hours and "decided to rush the pending next release", shortening the cycle by two weeks, which also let it fix many more vulnerabilities and bugs in the same release. Hacker News adds that the project pre-announced a High fix on 7 October. The curl-library archive for October holds no such message, and the oss-security index for 7 October has no curl entry, so that rests on Hacker News alone.

What the figure does not show: when the flawed code was written, beyond curl's statement that the problem was introduced in a commit tagged 8.12.0; when anyone outside the project first saw it; or whether anyone used it. The 29 days from report to release is derived from curl's own dates, under a policy that says disclosure should be "as soon as possible", usually with the next release, and allows an earlier separate release if the next is too far away. The 616 days measures how long the flaw sat in shipped releases and the 29 days measures how long the project took once it knew. They are different clocks, and the record gives no figure for the time between the two.

"A library", "client-side" and a version number are labels, not controls

The advisory carries its own warning: "libcurl is used by many applications, but not always advertised as such!" The project's Rock-solid curl page describes curl as used in cars, televisions, routers, printers, medical devices and set-top boxes among other things, and puts its installations at "over twenty billion". That is the vendor's description and a vendor's figure, not a count this briefing can check. What it shows is that "a library" is a label for code that runs inside other products, where nobody lists it as a product, nobody gets a notice and a supplier decides when it is updated.

"Client-side", in The Hacker News headline, sounds safer than server-side and hides a question. The flaw needs the program that uploads to be talking to a server the attacker controls, with a certificate that passes the program's checks: curl's lead developer wrote that the certificate "must remain valid" and that the upload must be roughly the right size, about 135KB. Any program using libcurl is a client when it uploads, including services in a data centre that push files or messages to addresses someone else supplies. The record does not count them. Whether an ordinary POST body counts as an upload in the advisory's sense, the advisory does not say. Inference: an application that turns certificate checking off removes the certificate condition, since any server then passes. curl does not say this, and no setting should be changed to "fix" it.

A version string is a label too. Debian's trixie security package is named 8.14.1-2+deb13u7. It reads as 8.14.1, a release curl lists as affected, yet Debian's tracker marks it fixed. Red Hat's page warns that "some security scanners that only consider the package version" report fixed packages as vulnerable. The same label cuts the other way. The advisory says 8.14.x is not affected from 8.14.3, 8.16.x from 8.16.2 and 8.20.x from 8.20.2, but those are Rock-solid curl builds, and curl's mailing-list post says to get them from the Rock-solid site "if you have a support contract". The advisory's list of fixed versions is not a list of things a reader can download. curl's maintainers sell Rock-solid support, so an advisory that names those builds is also a commercial pointer. The public fix is 8.23.0.

What the distributions and vendors said on 14 October, and what they did not

These pages were read between 19:05 and 19:30 BST on 14 October 2026, the day of release. They will have changed. Windows, macOS and Android vendors and appliance makers were not read.

Distribution and vendor status for CVE-2026-92392, as read by 19:30 BST on 14 October 2026. Package names are as the pages print them.

Source	What it listed	Not stated
Debian security tracker	trixie 8.14.1-2+deb13u7 fixed (DSA-6558-1); trixie base 8.14.1-2+deb13u5 vulnerable; bookworm not affected, vulnerable code not present; forky 8.22.0-1 vulnerable; sid 8.23.0-1 fixed.	A fixed forky package. The notice page itself sat behind a script challenge, not bypassed.
Ubuntu	26.04 LTS: fixed in 8.18.0-1ubuntu2.8, notice USN-8927-1 of 14 October. 24.04, 22.04, 20.04, 18.04, 16.04 and 14.04: not affected. Priority High, because upstream rated it High.	Anything for other flavours or extended support.
Red Hat	Important, CVSS 8.1 preliminary. RHEL 8 and 9 not vulnerable. RHEL 10 curl: Affected. Hardened Images curl: Affected. Satellite 6 openvox-agent: Affected, puppet-agent: Not affected.	A fix date or errata for any affected row.
Alpine	edge main: curl 8.22.0-r0, built 2 September 2026. The security tracker had no entry for the CVE.	Whether a fix is queued.
Fedora	Package page: Rawhide 8.23.0~rc3-1.fc46; Fedora 45 8.21.0-6 (testing 8.21.0-8); Fedora 44 8.18.0-14; Fedora 43 8.15.0-10 (testing 8.15.0-11).	Whether any carries the fix. The updates system sat behind a bot check, not bypassed. The rc3 snapshot of 7 October predates the 12 October fix commit (derived from dates).

Two things show the label problem in practice. In Red Hat's table the affected component in Satellite 6 is openvox-agent, a name that does not mention curl, while puppet-agent in the same product is Not affected. A search of a software inventory for the word curl would miss the first. And the older builds are outside this advisory only because they predate the flawed code: Debian says vulnerable code is not present in bookworm, and Red Hat says RHEL 8 and 9 ship builds preceding the introduction. Ubuntu lists 24.04 and earlier as not affected without saying why. That is not a security recommendation: the same release fixes 23 Low advisories, the earliest first affecting 7.10.8 (derived from curl's table).

Twenty-four advisories in one release, and a fix titled like housekeeping

curl's mailing-list post says the project publishes "twenty-four separate vulnerabilities" with 8.23.0, one High and the rest Low. The 24 advisory files agree: 1 High, 23 Low (derived). Twenty-one name 8.22.0 as the last affected version and three name 8.21.0. The credit lines name one organisation, Aisle Research, as a finder on 18 of the 24, Anthropic on two, and four other single finders on one each (derived; the credit lines also print individuals' names, which this briefing does not use). curl's table lists 69 advisories published in 2026 so far, across six release days, against 9 in 2025 and 11 in 2024 (derived). The table does not say why. On 1 May 2026 the NCSC told organisations to prepare for a "patch wave" and to be ready to update "including across their supply chains"; curl's table does not say that this is that wave.

The fix itself reads like housekeeping. The 8.23.0 changelog lists 4 changes and 283 bugfixes, which agrees with the release table (derived), eight of them begin "http2:", and the page names no CVE. The line that matches the fix commit's subject is "multi: adjust the cleanup order in multi_done". The commit the advisory links is six insertions and six deletions in one file, authored on 12 October, two days before release. Its message is the subject line and a pull request reference. curl's policy says a Low or Medium fix may merge through a normal pull request without saying it is a security fix, and that the default is a private branch, merged no more than 48 hours before release. To find which of 283 lines is the High, a reader needs the advisory's commit link. The changelog alone would not say.

What curl documents as mitigation, and where it stops

The advisory gives three recommendations: upgrade to 8.23.0, apply the patch to your local version, or do not use HTTP/2. For the third, the curl tool's man page says that for HTTPS curl negotiates HTTP/2 in the TLS handshake and "does this by default", and its --http1.1 option selects HTTP/1.1. For libcurl, the CURLOPT_HTTP_VERSION page lists an option that enforces HTTP/1.1 and says the default is to let libcurl choose since 8.13.0, and was HTTP/2 over TLS from 7.62.0. The same page says the version is a request: libcurl "still prioritizes to reuse existing connections", so it may reuse a connection that is on a version you did not ask for. A setting that looks like a switch is a preference, so test it.

Whether a build can use HTTP/2 at all is a feature of the build. The man page says the Features line printed by the version option includes HTTP2 when HTTP/2 support has been built in. The advisory itself says only not to use HTTP/2. The Hacker News adds that a build without it cannot reach the path, which is consistent with the advisory but is not stated there.

curl --version

Nothing in curl's documents offers a detection signature, and none is given here. The likely outcome curl describes is a crash, so the useful evidence is a crash in a process that has just uploaded to an unfamiliar server, kept with the connection log.

Who found it, and whose interest that serves

curl's advisory credits two finders: a reporter credited as working with Claude, and Anthropic. The lead developer's post says the problem was found and reported by a researcher at Anthropic using its new OSS Scanner, adding "Presumably this involves their AI models." Anthropic's launch post of 8 October 2026 says the scanner's outputs are "fully model-generated, without human review or triage", and quotes the same developer saying the scanner helped find "one of the worst curl vulnerabilities reported in the last few years". Neither page says whether a person reviewed this report before it was sent, how much of the work the model did, or what it cost.

Anthropic sells the models credited here and, per its own launch post, a code scanning and patching product aimed at enterprises, so a High finding in a library this widely used is also evidence for its product. That does not change what curl's advisory states. The same developer wrote in July 2025 that about 20 per cent of curl's security submissions that year were AI slop and that about 5 per cent had turned out to be genuine vulnerabilities. The record shows that change and not the reason for it. For how the scanner sends reports and what it says about review, see our earlier briefing (OSS Scanner skips human review).

UK: what the guidance says, as read, and where it goes quiet

Counting from release day, 14 October, the NCSC's best-practice timescales fall on Monday 19 October for internet-facing services (5 days), Wednesday 21 October for operating systems and applications (7 days), and Wednesday 28 October for internal or air-gapped software (14 days), the same day the Cyber Essentials 14 days ends (derived). Each source below was read on its own page.

UK guidance and law as read on the primary pages, 14 October 2026. None of them mentions curl.

UK source	What it says	Where it goes quiet
NCSC vulnerability management, update by default (version 2.1, reviewed 1 May 2026)	Install all updates as soon as possible. Timescales of 5 days for internet-facing services and software, 7 days for operating systems and applications, 14 days for internal or air-gapped, "regardless of the vulnerability severity". Attackers "will often study" a fix and write exploits.	A library embedded in a product you cannot update yourself.
Cyber Essentials, requirements for IT infrastructure v3.3 (April 2026)	Update within 14 days of release where the vendor describes the fixed vulnerabilities as critical or high risk, the CVSS v3 base score is 7 or above, or the vendor gives no detail. If one update covers any such issue it must be installed within 14 days. Software is defined to include libraries.	Whether curl's word High meets high risk. curl publishes no CVSS, Red Hat's 8.1 is its own and preliminary, NVD has none. An assessor decides.
Software Security Code of Practice (gov.uk, voluntary, updated 15 January 2026)	Vendors should understand component composition (1.2), manage vulnerabilities in components (3.3) and provide timely security updates and notifications (3.5). For open source the maintainer "bears no formal commitment to their onwards supply chain" and risks "must be managed by end-users or proprietary developers".	Any duty on curl's maintainers. The duty sits with whoever ships libcurl inside a product.
NCSC, SBOMs and the importance of inventory (11 September 2024)	An SBOM lists a product's components, and the inability to produce one is "a red flag". Paired with scanners it finds known vulnerabilities. In the NCSC's words, an inaccurate SBOM "offers false assurance".	How many SBOMs list a vendored libcurl correctly.
UK GDPR Article 32 (legislation.gov.uk, as revised)	Controllers and processors must implement appropriate technical and organisational measures, taking account of the state of the art and the risk, including a process for regularly testing and evaluating them.	Patch deadlines, libraries and curl. It names no update timescale.
NCSC Cyber Assessment Framework 4.0, A4.b (reviewed 6 August 2025)	For essential functions, Achieved includes a supplier that can show a thorough understanding of the composition of software, including third-party components, monitored for new vulnerabilities.	Anything outside operators of essential functions.

The NCSC's patch wave blog of 1 May 2026 adds that automatic updates, including for embedded devices, should be enabled where available, and that larger organisations should seek assurance from supply chains "both commercial and open source". Read together, the guidance puts the clock on the organisation that runs the software and the duty to supply a fix on whoever sells it. For software that is open source and embedded in a product, the Code of Practice says the risk is yours or your supplier's. Nothing in the guidance read says which.

Ordered checklist: what to do, in the order worth doing it

The question this leaves

curl's lead developer wrote that the project has spent years reducing the internal pointers that this class of bug depends on, and that this is "no guarantee" against another use-after-free. He added that the project does not plan to rewrite curl in another language. The next planned release is 9 December 2026.

The advisory says libcurl "is used by many applications, but not always advertised as such". Can you name, today, every program in your estate that carries a copy, which of them upload to servers you do not control, and who is responsible for shipping the fix for each?

Key facts