The Fix Wasn't a Patch

Greg Heffner August 31, 2026

I spent last weekend standing up Greenbone in the lab after retiring Nessus, and between the new scanner and the Wazuh SIEM already watching the fleet, I got handed a weekend's worth of homework. Wazuh flagged a Linux kernel CVE sitting on the CISA KEV list with a remediation due date of the next day. Greenbone's first credentialed sweep found six separate 9.8s on the QNAP that holds every backup I have.

Here is the part that made it a good weekend instead of a bad one: neither problem had a patch available. And neither fix ended up being a patch.

The Score Is Not the Decision

A CVSS score is like the national weather forecast: a real number, honestly produced, that still tells you nothing about whether it is raining in your backyard. The score describes the vulnerability. The decision has to describe your environment. Every finding in this post went through the same four questions I use at work:

• Is it in CISA KEV? Is anyone exploiting it in the wild?
• Is it actually reachable, past whatever mitigations are already in front of it?
• Is it on something that matters?
• Are there compensating controls, or an accepted risk already on the record?

Different answers route to different outcomes: fix now out of cycle, mitigate or accept on the record with a revisit date, or let it ride the normal patch cadence. That last one is not laziness. Most findings belong there, and saving the out-of-cycle alarm for things that earn it is what keeps people listening when you pull it.

Case 1: A KEV Deadline With Nothing to Install

CVE-2026-53362 is a local privilege escalation in the kernel's IPv6 stack. CISA added it to the KEV catalog on August 27 with a due date of August 30. Wazuh flagged it on every Linux host I run: the Docker host and all four Kubernetes nodes.

First stop, the obvious one: patch it. Except there was nothing to install. Every host was already on the newest kernel Ubuntu publishes, and canonical-livepatch status came back nothing-to-apply. Canonical had not shipped the fix yet. A KEV deadline was about to blow past and apt had nothing for me.

So the fix-now leg of the tree fired, but it could not mean patching. It meant taking the vulnerable subsystem off the board. Nothing in my lab actually uses IPv6, which made the mitigation obvious: disable it everywhere, on the record, and let the eventual kernel update land in the normal Saturday patch run whenever Canonical ships it.

Turning off a network stack across a whole fleet over SSH is exactly the kind of change that can saw off the branch you are sitting on, so the rollout looked like this on every host:

• Check what is actually listening on IPv6 first: ss -lntup
• Grep Kubernetes and kubelet configs for ::1 bindings so the cluster does not eat it
• Check sshd for ListenAddress and AddressFamily so I do not lock myself out
• Arm a dead man switch before changing anything: a systemd-run timer that re-enables IPv6 automatically in 10 minutes unless I cancel it
• Apply the sysctls, keep loopback enabled, confirm the session survived, then persist to /etc/sysctl.d/99-cve-2026-53362-ipv6.conf

The auto-revert timer is the piece I would push hardest on. If the change had broken connectivity, doing nothing for ten minutes would have fixed it. And the sysctl file is named after the CVE on purpose, so that future me finds the why attached to the what instead of a mystery config nobody remembers.

Verification: zero global IPv6 addresses on every host, the subsystem the CVE lives in is dark, and the finding moved to accepted-with-mitigation status with a revisit tied to the kernel update. When Ubuntu ships the fixed kernel, the weekly Ansible patch run picks it up with no ceremony at all. The patch cycle is a feature.

Case 2: Six 9.8s on the Backup Box

The QNAP case started with me catching my own tooling in a lie, which is worth being honest about. I had built a false-positive filter for Greenbone results, because Ubuntu backports security fixes without bumping version strings and version-matching scanners fall for it constantly. The filter worked great. It also worked on findings it had no business touching: I had applied it to every host, including the appliances, and appliance firmware makes no backport promises at all.

When I scoped the filter back down to just the Ubuntu fleet, out fell six Netatalk RCEs on the QNAP, every one of them CVSS 9.8, plus friends. Netatalk is the AFP file sharing daemon, the finding was based on the live service banner rather than a package list, and a direct connect test confirmed port 548 was open and answering. This was not dormant code. It was a listening service with a pile of remote code execution CVEs, on the box that holds all my backups, in the product family that ransomware crews have historically gone straight at.

Same four questions. Reachable: yes, proven. On something that matters: about as much as it gets. Patch: no. QNAP's firmware was current, and the bundled Netatalk was simply the version they ship. The vendor patch lever did not exist.

Then the question that actually mattered: was anything using AFP? Zero established connections on 548. Every one of my mounted shares was already on SMB. The service was pure attack surface with no job. So the fix was not a patch and not a workaround. It was a checkbox: disable AFP in the QNAP UI, confirm 548 stopped answering, confirm every SMB share still worked, and rescan. The follow-up Greenbone run came back with zero Netatalk findings. Six criticals gone by deleting a service nobody would miss.

Three Dispositions, Zero Patches

One weekend, and the decision tree produced three different outcomes:

• Kernel KEV: mitigate out of cycle (subsystem off, dead man switch, on the record), then hand the real fix to the normal patch cadence.
• Netatalk on the NAS: eliminate the attack surface entirely. The best patch is a service that no longer exists.
• Everything else the scan found: normal cycle. And that is fine.

If I had triaged by severity score alone, the weekend looks completely different: six 9.8s screaming at the top of the queue with no patch to apply, a High further down the list quietly blowing through a federal remediation deadline, and me refreshing vendor pages waiting for updates that were not coming. Score-based triage had no move to make. Risk-based triage had two.

Final Thoughts

None of this required anything exotic. Four questions, a bias for proving reachability instead of assuming it, the discipline to write down what you accepted and why, and enough operational paranoia to arm the auto-revert before you touch a network stack you are currently standing on.

The severity score gets a vulnerability into the room. It should never get to make the decision. That job belongs to reachability, blast radius, and what your environment actually runs, because sometimes the right fix for a 9.8 is a patch, and sometimes it is a checkbox that was waiting years for someone to ask why the service was on.

Stay safe online!