The Allure of the Perfect Ten

# The Allure of the Perfect Ten Everyone in the industry is talking about some new, scary shift in how fast attackers move. They're pointing to CVE-2026-85706, that path traversal bug in GitLab; it hit a CVSS 10.0, which is the highest score you can get. Word is it was exploited within 24 hours after it went public, and to a panicked CISO or some random observer, this looks like the gap between patching and getting hacked has just vanished. The story is easy to tell. Vendors can't announce a bug without giving attackers a map, and the speed of the attack has finally beat the speed of human admin work. It's a tidy story. It's also mostly wrong. Let's talk about the 10.0 score, and in my world, "critical" is a word you have to earn, but CVSS scores usually end up as math artifacts instead of real risk markers. A 10.0 doesn't mean your server is burning down right now. It just means that, based on a formula, the flaw is easy to trigger and has a high impact. The formula forgets about network segmentation or WAF rules that might stop a path traversal attempt before it ever touches the application. I've watched CVSS 7s do way more damage than 10s because those 7s lived in components people actually used and forgot to lock down. Then we have this "one day" window; people who don't read changelogs love the fantasy that attackers are suddenly getting faster. They aren't waiting for a blog post to tell them where the hole is. They just diff the binaries of the fix against the old versions. When GitLab pushes a patch on Friday, some script is already comparing those two versions by Friday afternoon, and seeing exploitation within 24 hours isn't an AI leap. It's basic reverse engineering that has been standard for ten years. The speed of the attacker isn't the real issue here, and the fragility of the target is. If you run GitLab and your first move is to stare at a CVSS score instead of checking if your instance is open to the public internet, you've already lost. There is a second-order effect that everyone is ignoring while they vibrate over the number ten. The danger isn't just read access from this path traversal. It's the CI/CD pipeline. If someone uses CVE-2026-85706 to steal a secret or compromise a runner, they aren't just taking source code. They are poisoning the well. Attackers can inject malicious code into build artifacts and push them into production across an entire company. The victim isn't just GitLab. It's every single customer using software built on those compromised pipelines. The crowd will argue that the speed of exploitation proves we need "autonomous security" or AI-driven patching agents to close the gap. This is where the hype becomes profitable. Who wins when a CVSS 10 hits? The vendors selling "instant remediation" tools. And the consultants billing by the hour to install them. They thrive on this panic, and treating every high score as an existential crisis justifies the budget for tools that claim to solve a problem. That problem, the patching gap, is really a failure of basic hygiene and architecture. Look past the GitLab noise if you want actual scale; IDScan confirmed a breach involving 153 million driver's licenses recently. That is not a "critical" vulnerability in one piece of software. It is a wholesale migration of identity data to the dark web. There are also 347,000 Trezor users who received phishing emails. Attackers found a SAML SSO flaw in Brevo, a marketing platform. No amount of "fast patching" on the end-user side could have stopped that supply chain failure. We know this pattern. Remember Log4j in 2021? People treated every mention of a JNDI lookup as a death sentence, and the obsession with the "magic bullet" vulnerability persists here. But the tooling for mass-scanning has become efficient enough to raise the noise floor significantly. Why are we still surprised by attacker speed? That is the real question, and I will change my mind when I see a vendor release a patch, only to have an exploit in the wild three weeks later. Until then, 24 hours is just business as usual. Check your versions now. If you run the affected GitLab build, update to the fix version immediately; do not do it because the score is a ten. Do it because path traversal is a boring, old way to lose your keys.