Why Kubernetes Just Made My Vulnerability Scanner Useless (And That's Actually Good)

I was running a security audit on one of our staging clusters last month when something weird happened. My vulnerability scanner—the expensive one we pay good money for—suddenly flagged three CVEs across all our Kubernetes nodes as fixed, even though our security team kept insisting they weren't. I spent two hours digging through changelogs and GitHub issues before I realized the scanner was just wrong. Turns out, Kubernetes has been sitting on a pile of unfixed vulnerabilities with broken CVE records for years, and nobody in my circle really talked about it.

Then I read the announcement. The Kubernetes Security Response Committee is finally correcting the record on June 1st, 2026, and when they do, tools like mine are going to light up like a Christmas tree. Not because your cluster suddenly became less secure, but because the CVE records will finally tell the truth: some vulnerabilities aren't getting patched. Ever.

This is uncomfortable. But it's also the conversation we need to have.

The Problem Nobody Wants to Admit

Kubernetes is mature software, but it's not flawless. The three CVEs being corrected—CVE-2020-8561, CVE-2020-8562, and CVE-2021-25740—have been public for years. My scanner probably flagged them as "fixed in version X.Y.Z" because that's what the CVE record claimed. Except that version number was fiction.

The real issue here isn't malice. It's architecture. These aren't bugs in the traditional sense. They're design decisions. The kube-apiserver following HTTP redirects, the DNS race condition in the proxy layer, the cross-namespace IP forwarding via Endpoints—these are features that some people need and others see as security problems.

Kubernetes chose to document them as fixed when they were actually just... accepted. That's the gap we're talking about.

Why This Matters to People Running Production

Here's what keeps me up at night: my scanner tells me what's broken. When a CVE record lies about whether something's fixed, my scanner becomes unreliable. And an unreliable security tool is worse than no tool at all, because you still trust it.

The Kubernetes team is essentially saying: "We can't fix these without breaking things people depend on. So we're going to be honest about it instead." That takes guts, and it's the right call.

But it means the burden shifts to us. We can't just run a scan and call it secure. We have to understand the actual risks and implement compensating controls.

What I'm Actually Going to Do

For CVE-2020-8561 (webhook redirects), I'm already restricting API server log verbosity and disabling dynamic profiling. That's straightforward—set --v < 10 and --profiling=false. It prevents an attacker from using log exfiltration if they compromise a webhook.

For CVE-2020-8562 (DNS TOCTOU), I'm deploying dnsmasq on my control plane nodes with min-cache-ttl configured. This is more friction—it's another component to maintain—but it guarantees the DNS resolution stays consistent between the check and the actual connection.

For CVE-2021-25740 (cross-namespace Endpoints), I need to audit my RBAC. This one actually scares me more because many operators and service mesh tools legitimately write to Endpoints. I can't just lock it down without breaking things.

# Example: Reconcile RBAC to remove Endpoints write access
# Run this to audit your cluster
kubectl auth reconcile -f - --dry-run=client <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: system:aggregate-to-edit
  labels:
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
rules:
- apiGroups: [""]
  resources: ["endpoints"]
  verbs: ["create", "delete", "deletecollection", "patch", "update"]
  # Remove endpoints from broad edit roles in older clusters
EOF

The key insight: these mitigations aren't about patching code. They're about reducing the blast radius of each issue and limiting who can actually exploit them.

My Take

I respect what Kubernetes is doing here. They're moving away from the "patch everything immediately" fantasy that never existed anyway. Real systems have tradeoffs. Real security is about understanding your threat model, not just running scanners.

But this also means the industry needs to grow up about vulnerability management. A CVE that affects "all versions" isn't a failure. It's reality. What matters is whether you're mitigating it.

My only concern is adoption. How many teams will see these flagged in their scanners next month and panic? How many will actually implement the mitigations versus just ignoring the alerts?

What's Your Plan?

If you're running Kubernetes in production, I'd seriously recommend auditing your setup against these three CVEs now—before the records get corrected and your scanner starts screaming. Check your API server flags, your DNS setup, and your RBAC policies.

What's your bigger question: what other architectural debt is sitting in your infrastructure that we're not being honest about?

Source: This post was inspired by "Reconciling the Past: Correcting Records for Unfixed Kubernetes CVEs" by Kubernetes Blog. Read the original article