A fabrication checker cleared an invented CVE because it asked the wrong question

A resolved CVE identifier carries more weight in triage than any other line in a report, because it looks like the one claim that was checked by someone outside the project. That is exactly the check with no project in it: the lookup goes to a global namespace that holds no opinion about which repository is under discussion ^[5]. What came back described a Linux kernel TPM fix ^[3], and for a report filed against the author's own project the honest output was never "real". It was "this identifier belongs to something else". Existence and relevance were collapsed into one boolean, and the boolean pointed the fabricator's way.

The same collapse runs in the other direction, and that one is more expensive. curl declares its options inside a macro call, and the C grammar has no rule for a macro-wrapped enumerator, so tree-sitter error-recovers and the boundary of the recovered ERROR node lands where it lands: two entries with identical syntax, 22 lines apart in one enum, gave opposite answers about whether the name was declared ^[13]. Older releases are worse. Through curl 7.62 the option names were assembled by the preprocessor, so CURLOPT_SSL_VERIFYPEER appears zero times in the header that declares it, and a grep-driven file chooser kept finding the docs that mention it instead ^[15]. A maintainer who gets a bare miss on a true claim does not read it as a wrong claim. They read it as a broken tool ^[14], and that reading is what gets software uninstalled ^[12].

So the measurement matters more than the demo. curl's 206 published advisories are human-written and were accepted as valid, and every claim in them was true of the release described ^[10], which makes any miss a false positive by construction, with the single controllable exception of checking an advisory against the wrong revision ^[11]. Running each one against HEAD and against the release it names is 412 runs ^[17], and the gap between those two rows prices the habit of not saying which release you mean ^[21]. Repairing the parser and the file selection took the pinned row from 24.0% unexplained to 3.1% ^[16]: 20.9 points, leaving roughly an eighth of the original error ^[18]. The four survivors are internal functions curl has since renamed or removed ^[16], which is the residue you would expect rather than the kind that ends trust. Documentation would have been the easier corpus and the wrong one, since it drifts and cites other projects ^[20].

Both bugs are one bug. A string was found somewhere, and the finding was reported as a fact about the project. One version of that mistake flatters a fabricated report and the other insults an honest one, and only the second gets reported back, because the triager who was reassured by a green CVE line has no reason to go looking ^[7].