A maintainer whose library sits in roughly 30 billion installs argues some flaws are so convoluted they don't deserve a public identifier — and won, after MITRE, the nonprofit that runs the CVE program, sided with him.
libcurl, the data-transfer library that ships inside apps, servers, and an estimated 30 billion installs worldwide, has spent four years doing its own vulnerability numbering. As a CVE Numbering Authority (CNA), the curl project can mint its own public identifiers for security flaws in its code, and on June 24, 2026, the project's lead maintainer, Daniel Stenberg, published a post about the first time a researcher asked MITRE to overturn that decision.
MITRE sided with curl. The question the case forces open is bigger than the bug: when a flaw is technically real, fixed, and fixed quickly, who decides whether it earns a CVE — and at what point does publishing one cost the ecosystem more than the flaw itself?
According to Stenberg, the issue sat in Curl_cert_hostcheck(), the routine that checks whether a server's wildcard TLS certificate matches the name in the URL. The flaw surfaced when a user supplied a URL with a leading dot — https://.example.com/ — a hostname that cannot resolve over DNS, would only work if an operator had hand-mapped it in /etc/hosts, and required a wildcard certificate for *.example.com plus a local attacker already in position to impersonate that host. For a connection to be hijacked, an attacker would need a user running a custom hosts entry, a redirect toward a name only that entry could resolve, a wildcard cert issued for the parent domain, and physical or local presence on the network. curl fixed the bug on December 8, 2025, added a regression test, and kept going.
The project then declined to assign a CVE. Stenberg's reasoning, which he lays out plainly on the blog, is that curl grades issues from LOW through CRITICAL but also recognizes an internal category for problems so unlikely to be reached in practice that the project calls them "lower than LOW." A CVE is not a free label. Every published identifier triggers downstream work — patches, audits, upgrade cycles — across the security teams that manage those 30 billion installs. None of that cost lands on the project that publishes the number.
The reporter who submitted the original finding disputed that call through the formal escalation path, asking MITRE to assign a CVE over curl's objection. MITRE returned to curl three times — in February, May, and June — asking for rationale. On June 24, the MITRE TL-Root issued a verdict: "This is a bug, now fixed in the master branch. It is not considered a security vulnerability because of how it requires a local attacker with privileges present to make it so." No CVE.
A June 15 community discussion opened by the CVE Program asked what happens when AI-assisted research starts finding flaws faster than humans can triage them. A satirical incident report circulated the same week described seven AI-powered scanners deferring to each other until a hidden honeypot told the attacker's autonomous agent to stand down. In that environment, the question of what a CVE actually certifies has become its own line of work — and disputing one is part of the job, as the Random in Security weekly summary put it.
The project does not hide bugs: the commit, the test, and the discussion thread on HackerOne are public. The fix shipped in the normal release cadence for issues below HIGH, which curl treats as a routine obligation regardless of CVE status. What the project reserves is the right to say, in writing, that a problem fixed in code does not need a parallel record that triggers ecosystem-wide work for conditions no realistic user will assemble. SUSE and Ubuntu maintain their own security trackers, and curl publishes a separate record for a related trailing-dot cookie flaw, CVE-2026-8924, where the conditions for harm are different and a public identifier was warranted.
The limits of that posture are part of the case, not an addition to it. Stenberg acknowledges on the blog that he cannot know how every user deploys curl, that a person actually affected by the leading-dot scenario might rate the severity higher than the project does, and that the ecosystem cost of a published CVE does not return to the team that issues it. A user running curl in a controlled environment with hand-maintained host mappings and redirect-following code is, by construction, closer to the conditions of the bug than the project's own threat model assumes. The defense of restraint depends on that gap staying narrow, and on the project continuing to publish the fixes regardless of the verdict on the identifier.
The Hacker News thread on the post split along the same fault line. Some readers read the case as a CNA exercising judgment; others read it as a small team declining to document a flaw that downstream package maintainers, integrators, and compliance teams would otherwise have to assess on their own. MITRE's TL-Root ruling closes the procedural file, but the underlying question — what does a CVE certify, and who pays when the certification runs ahead of the harm — is now part of the public record, and stays open.