Skip to content

Those Kubernetes CVEs You Thought Were Fixed? About That...

Turns out "marking a CVE as fixed" and "actually fixing it" are different things. The Kubernetes Security Response Committee is correcting public records for three vulnerabilities - CVE-2020-8561, CVE-2020-8562, and CVE-2021-25740 - that have been sitting in the CVE database with erroneous "fixed" statuses for years. On June 1, 2026, those records get updated to reflect reality: these issues are still there, have always been there, and aren't going away.

What Actually Happened

While improving the Kubernetes CVE feed and OSV file generation, the security team noticed that three CVEs had fixed version fields that shouldn't exist. The vulnerabilities themselves aren't new discoveries - they've been known and documented since 2020 and 2021. The problem is that they're architectural tradeoffs baked into how Kubernetes works, not implementation bugs you can patch out of existence. Fixing them properly would mean breaking core platform behavior, so the project made a deliberate decision to accept and document them rather than ship a "fix" that causes more problems than it solves.

The metadata, however, suggested otherwise - which is what's getting corrected.

Why Your Scanner Is About to Get Loud

If your organization runs any kind of automated vulnerability scanning - and it does - expect things to get interesting around June 1. Scanners that were previously dismissing these CVEs as resolved will start flagging them as unpatched. The underlying security posture of your clusters hasn't changed at all, but the tooling will act like something new just appeared.

This is the fun part: these aren't freshly discovered vulnerabilities. They've existed in every version of Kubernetes you've ever run. The database just had the wrong answer.

The practical blast radius depends on how aggressive your security gates are. CI/CD pipelines with hard CVE thresholds, container registries with policy enforcement, compliance dashboards with executive-visible status - all of these are candidates for unexpected alerts. If your security posture relies on "zero unresolved critical CVEs," you'll want to get ahead of this before it becomes a 9pm page.

What To Do Before June 1

The good news is this is entirely manageable with a little prep:

  1. Find everything that consumes CVE feeds. Registries, CI gates, runtime scanners, compliance tooling - make a list. Know which ones are currently treating these three CVEs as resolved.

  2. Read the actual CVE descriptions (CVE-2020-8561, CVE-2020-8562, CVE-2021-25740). These are architectural issues, not exploits you can stumble into by accident. Whether they're material to your environment depends on your specific configuration, network policies, and threat model. Do the actual risk assessment rather than letting the scanner do it for you.

  3. Prepare your exceptions now. Most enterprise tools support suppressing specific CVEs with a documented business justification. "This is a known architectural tradeoff with no available fix, acknowledged and accepted by the Kubernetes project" is a legitimate rationale. Write it once and apply it everywhere rather than explaining the same thing to five different teams after the alerts start firing.

  4. Brief your stakeholders before the dashboards do. Nothing generates more unnecessary urgency than a compliance dashboard suddenly showing critical unresolved CVEs on infrastructure that hasn't changed. A short heads-up explaining the situation - "records are being corrected, not new vulnerabilities discovered" - saves everyone a lot of time.