Catching a False Positive: What a Patched regreSSHion Finding Taught Us

📖 5 min read | 920 words

Vulnerability scanners are supposed to tell you what’s actually at risk. But every scanner — commercial or open source — produces false positives, and most MSPs either don’t catch them or don’t talk about it publicly. We do.

This month, as part of building our in-house vulnerability scanning pipeline, we ran a full external scan against one of our own production servers. The scan flagged a critical-severity finding. On investigation, it turned out to be a false positive — and the reason why is a useful lesson for anyone relying on scan output without verifying it.

The Finding

During a full external scan of one of our own hosts (158.69.113.109, a production web server we operate), our scanning pipeline flagged a CVSS 8.1 finding tied to CVE-2024-6387, widely known as “regreSSHion” — a real, serious OpenSSH vulnerability that affected systems worldwide in 2024. It was the highest-severity result out of 45 total findings in the scan.

A critical remote vulnerability in SSH is the kind of thing that demands an immediate response. So we verified it before acting on it.

How We Verified It

Rather than trust the scanner’s banner-grab and version match, we checked the host directly: OS version, OpenSSH package version, and — critically — the distribution’s own changelog for that package.

Why It Was Wrong

The host was running Ubuntu 22.04.5 with OpenSSH 8.9p1-3ubuntu0.18. On paper, that version string matches builds vulnerable to regreSSHion. But Ubuntu, like most major distributions, backports security fixes into existing package versions instead of always bumping the version number. The package’s own changelog confirmed CVE-2024-6387 had already been patched on this build.

The scanner was reading the version string, not the patch state. That’s a known limitation of signature-based vulnerability scanning — and exactly the kind of gap that produces a false sense of urgency (or, just as dangerous, a false sense of security if the process stops at the version check instead of going further).

Why This Matters for Your Business

This is the difference between a scan report and a security program. A raw scanner output is a list of things to check — not a list of confirmed risks. Anyone can run a scan and hand you a PDF of red and orange severity scores. Verifying each finding against the actual system state before it reaches a client is the part that actually determines whether their time gets wasted chasing phantom vulnerabilities or spent fixing real ones.

It’s also why we’re building this scanning capability in-house rather than relying solely on third-party tools: it lets us control not just what gets flagged, but how it gets verified before a client ever sees it.

Conclusion

A critical CVE on paper turned out to be a non-issue in practice — because the distribution had already patched it under the same version number. That’s not a knock on vulnerability scanning; it’s why scanning alone isn’t a security program. Verification is.

If your current IT provider is handing you raw scan reports without this kind of check, ask them how findings get verified before they reach you.