curl shipped nine security fixes on September 2, 2026. NVD published the records four days later with no score, no CWE, and no version data — including the one that is a wider, older sibling of a June flaw CISA rated 9.1.
What happened
The curl project released curl 8.22.0 on Wednesday, September 2, 2026, closing nine advisories in curl and libcurl. The National Vulnerability Database published the corresponding CVE records on Sunday, September 6 — four days later, most of them stamped 6:17 p.m. UTC, with one arriving at 11:17 p.m. UTC. The NVD publication is the new development here; the fixes themselves are five days old.
All nine records landed in the same condition. Each carries vulnStatus of Received, an empty metrics object, no weaknesses array, and no configurations block. No CVSS score, no CWE, and no CPE — which is the field a version-matching scanner needs in order to tell you that the curl in your build is affected.
The item that matters most in the batch is CVE-2026-80231, which curl titles “Native CA store conn reuse” and rates Low. The advisory says the flaw makes libcurl “wrongly reuse an existing HTTPS connection setup for a given hostname even when using a different Native CA Store setting (CURLSSLOPT_NATIVE_CA) than when the connection was created.” It affects curl 7.71.0 through 8.21.0 on Windows and macOS, in both libcurl and the command-line tool, and is fixed in 8.22.0. Stanislav Fort of Aisle Research reported it on August 24, 2026; Daniel Stenberg wrote the patch.
Ten weeks earlier, curl 8.21.0 shipped on June 24, 2026 carrying CVE-2026-11564, “Native CA trust persist” — also rated Low by curl, also about native platform trust surviving a configuration change, also on Apple and Windows builds. Its description: “An easy handle that first uses default native CA trust can continue trusting the native platform store after the application switches that same handle to custom CA material for a later transfer.” It affects curl 8.17.0 through 8.20.0. Filipe Casal of Trail of Bits reported that one.
These are two distinct mechanisms, and the September advisory does not reference the June one. CVE-2026-11564 is about per-handle trust state: the handle keeps the platform store after the application hands it custom CA material. CVE-2026-80231 is about the connection pool’s match key: libcurl decides a pooled connection matches the current setup without checking whether the native CA setting is the same one that built it. Different code paths, same question — does libcurl’s reuse machinery notice when TLS trust changes underneath it — answered twice, ten weeks apart.
The second answer covers far more ground than the first. CVE-2026-11564’s affected range begins at 8.17.0. CVE-2026-80231’s begins at 7.71.0, dozens of minor releases earlier, and it reaches the command-line tool, which the June flaw did not.
The two records look nothing alike
NVD published CVE-2026-11564 on July 3, 2026. It is now in Analyzed status. It carries CWE-295, Improper Certificate Validation. It carries a CPE configuration naming curl 8.17.0 through 8.20.x. And it carries a CVSS v3.1 base score of 9.1, CRITICAL, vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N.
That score is not NVD’s. The record holds exactly one CVSS entry, typed Secondary, from source 134c704f-9b21-4f2e-91b3-4a467353bcc0. NVD’s own source index resolves that UUID to CISA-ADP, the Authorized Data Publisher channel CISA runs to enrich records CNAs leave thin. There is no Primary entry from [email protected]. curl, as its own CNA, does not assign CVSS scores at all; it publishes a plain-English severity word instead. So the 9.1 on the June flaw is CISA’s reading of a bug curl called Low, and NVD has never scored it.
CVE-2026-80231 has none of that. As of this writing it is a bare record: curl’s description, three reference links, and nothing else.
The rest of the batch
The other eight, all fixed in 8.22.0 and all published to NVD in the same bare state: CVE-2026-13608, an OpenLDAP SASL authentication bypass in which “an incomplete handshake sequence” is “misinterpreted as a successful cryptographic verification” (7.82.0 through 8.21.0, reported by Eunsoo Kim of Microsoft’s Autonomous Code Security team); CVE-2026-18924, an HTTP/2 Server Push use-after-free (7.44.0 through 8.21.0, Stephan Zeisberg of Security Research Labs); CVE-2026-19931, “Negotiate ambient user conn reuse,” the one item curl rates Medium, where blank Negotiate credentials are treated as ambient and a connection authenticated as one user is reused for another (7.64.1 through 8.21.0, Martin Dukek); CVE-2026-80229, a heap use-after-free when pooled OpenSSL 3 provider connections outlive the easy handles that created them (8.14.0 through 8.21.0); CVE-2026-80230, in which CURLOPT_PINNEDPUBLICKEY is not enforced on connections where no server certificate is presented (7.45.0 through 8.21.0); CVE-2026-80255, where a tab before the Secure attribute in a Set-Cookie header makes curl store the cookie without its Secure flag (8.13.0 through 8.21.0); CVE-2026-82208, where a wolfSSL CA cache hit reinstalls the cached trust store over one a CURLOPT_SSL_CTX_FUNCTION callback replaced (8.9.1 through 8.21.0); and CVE-2026-82209, where a cookie whose Domain matches a public suffix is stored with wildcard scope (7.46.0 through 8.21.0). Fort reported six of the nine.
Why it matters
Three parties have now expressed an opinion about how bad libcurl’s native-CA trust handling is, and they do not agree by four and a half points. curl says Low. CISA’s enrichment channel says 9.1 Critical. NVD says nothing, twice. A defender reading only the vendor advisory files this under housekeeping. A defender reading only the scanner output treats June’s as an emergency and September’s as nonexistent.
That last case is the practical failure. An organization that patched curl in June did so because something in the pipeline surfaced a 9.1 against a matched CPE range. The September flaw is the same setting on the same platforms, it reaches many releases further back, and it additionally affects the command-line binary. It will surface nowhere, because the record has no CPE to match and no score to sort by. The team most likely to miss it is the one whose June response worked.
curl’s position on CVSS is long-standing and openly argued: the project holds that a context-free base score misleads more than it informs, given how differently libcurl gets embedded. That is a deliberate editorial choice, not an oversight. The consequence is that a curl record is only ever as actionable as whatever enrichment arrives after it, and enrichment arrives on nobody’s schedule. June’s record got CISA-ADP within about a week. September’s has not got it in four days, and there is no published commitment that it will.
Six of the nine came from one researcher at Aisle Research over a three-week window in August, and a seventh from a team Microsoft calls Autonomous Code Security. Machine-assisted auditing is producing curl findings faster than the record pipeline enriches them. The bottleneck for a defender has moved: the bugs are found and fixed promptly, and what fails is the metadata that would have told you which build to rebuild.
There is also a pattern inside the nine that the individual Low ratings hide. Four of them — CVE-2026-80231, CVE-2026-82208, CVE-2026-80230, and CVE-2026-19931 — are the same shape: libcurl decides a connection or a trust store “matches the setup,” and the security-relevant parameter turns out not to be part of the match. Add June’s CVE-2026-11564 and that is five in two consecutive releases. Rated one at a time, each is a Low. Read together, they say libcurl’s reuse and caching layers are still discovering which of their inputs are security decisions.
What to do
Upgrade curl and libcurl to 8.22.0. That closes all nine.
Do not wait for a scanner to raise it. These records carry no CPE, so version-matching tools will not fire on them for as long as they stay in Received status. Inventory by build instead: anything statically linking libcurl, any vendored copy in a container image, any language binding that ships its own libcurl. The command-line tool matters here too, unlike in June.
Where you cannot upgrade quickly, curl publishes per-advisory workarounds. Set CURLOPT_FORBID_REUSE on transfers that use the native CA store (CVE-2026-80231), on transfers using blank Negotiate credentials (CVE-2026-19931), and on OpenSSL provider-based transfers (CVE-2026-80229). Avoid CURLOPT_SSL_CTX_FUNCTION with the wolfSSL backend (CVE-2026-82208). Disable HTTP/2 Server Push if you set CURLMOPT_PUSHFUNCTION (CVE-2026-18924). Stop using unencrypted ldap:// (CVE-2026-13608).
If you patched for CVE-2026-11564 in June on the strength of the 9.1, check specifically for CVE-2026-80231 now. The June fix does not cover it, and your tooling is unlikely to tell you.
Sourcing note
Checked: curl’s advisory pages for all nine CVEs and for CVE-2026-11564; curl’s vuln.json database; the NVD REST API records for CVE-2026-80229, CVE-2026-80231, CVE-2026-82209, and CVE-2026-11564; and NVD’s source index, which resolves 134c704f-9b21-4f2e-91b3-4a467353bcc0 to CISA-ADP. Version ranges, severities, reporter credits, and timeline dates come from curl’s advisories. Record status, CVSS entries, CWE, and CPE presence come from the NVD API responses.
Not reached: cisa.gov returns 403 to automated fetching, so CISA’s Vulnrichment repository was not read directly; the CISA-ADP attribution comes from NVD’s source index and the record’s own source field, which is NIST republishing CISA. NVD’s HTML detail pages render client-side and returned no content, so all NVD facts here are from the JSON API.
Unresolved: whether CISA-ADP will enrich the September records, and on what timeline. The gap between curl’s Low and CISA’s 9.1 on CVE-2026-11564 is unexplained by either party — CISA-ADP entries carry no rationale, and curl does not publish CVSS. Whether NVD will ever assign a Primary score to either record is unknown; neither has one now.