Why I’m writing this#

I had just finished patching the homelab Proxmox host and 11 LXCs in one sweep. My CVE gating script (scan-all-cves, twelve checks across distro and version) flagged five [VULN]s. I worked through all five, then ran Lynis and Docker Bench on the host. The hardening scores were ugly.

CVE list clean, system not actually safe. Once is a coincidence; this pattern repeats. It runs against the way CVE gating gets framed as the core of host security. Writing this so the next person doesn’t reinvent the lesson.

Scanners can’t see distro silent backports#

Two of my [VULN] hits were glibc CVEs. Reading Debian’s changelog directly:

1
$ zcat /usr/share/doc/libc6/changelog.Debian.gz | grep -i CVE-2026-0861
2
  (CVE-2026-0861).  Closes: #1125678.

Already fixed. The tool isn’t lying — it’s blind by design. detect.sh-style scripts compare against a per-distro cutoff version. When Debian keeps the same version number and backports the security fix — which is common — the cutoff comparison still flags [VULN].

The pattern repeats across RHEL, Ubuntu LTS, anywhere with heavy backporting. To not take the tool at face value, you have to read the changelog yourself or cross-check against the distro’s security tracker (security-tracker.debian.org, ubuntu.com/security/cves).

Compile flags can erase a vulnerable path entirely#

sudo CVE-2026-35535 is the more interesting case. Debian never issued a DSA. The CVE stayed [VULN] in my scan. At first I assumed Debian was just slow. The actual reason was specific.

Debian’s sudo is built with --disable-root-mailer, which means the vulnerable code path isn’t compiled into the binary at all. The CVE exists upstream, but the binary in this distro can’t be exploited because the path is gone. Debian classified it as “minor issue” — a deliberate decision.

There’s no way for the scanner to know this. Comparing package version to a CVE table tells you nothing about how the package was built. To verify actual exposure:

1
# Build options
2
dpkg -s sudo | grep -i config
3

4
# Check the binary itself for the suspect path
5
strings /usr/bin/sudo | grep -i mailer

At this layer the [VULN] is a false alarm. Real exposure depends on distro policy plus the binary itself. This is exactly where automation stops being useful.

The actual holes in a CVE-clean system#

After the five CVEs (with two false positives discounted), I ran three hardening scanners against the host.

• Lynis: hardening index 64/100 (60-80 is the “improve” zone)
• Docker Bench for Security: 11/105 passed
• ssh-audit: 6 [fail]s — NIST P-256/384/521 curves, SHA-1 MACs still advertised

The opposite picture from the CVE scan. The failures are familiar names:

• No fail2ban — zero brute-force protection
• No GRUB password — physical access drops to single-user mode unchallenged
• Docker daemon not under auditd — container activity untracked
• sshd advertising weak KEX/Cipher/MAC — downgrade-attack surface

None of these would show up in any CVE database. They aren’t package version problems — they’re consequences of default configuration. And from a real risk-reduction standpoint, this side often matters more. Installing fail2ban and enabling five jails takes five minutes; the result is SSH brute-force coverage. Five minutes spent on a single CVE patch can’t compete.

Scanner output is a hypothesis, not a conclusion#

This isn’t an argument against CVE gating. It’s an argument against treating CVE gating as the whole security posture. Two more steps belong in the loop.

First, don’t accept [VULN] verdicts at face value. Reading distro changelogs and checking binary compile flags eliminates close to half of false positives in my experience. Understanding the limits of automation actually makes its output easier to trust — paradoxically.

Second, run hardening scanners on a regular cadence. Lynis runs in five minutes. Docker Bench is similar. That five minutes often closes more risk than the previous ten CVE patches did. A fully patched but weakly configured system tends to be less safe than an unpatched but well-hardened one.