Quick answer: Kubernetes corrected several old CVE records on June 1, 2026, so vulnerability scanners may now surface issues that were always real but poorly represented. That does not mean your team suddenly has a patch to apply. It means your triage process needs to get smarter.
TL;DR
- Kubernetes said some older, unfixed CVE records incorrectly showed fixed versions.
- The project corrected those records on June 1, 2026 and warned that scanners may start detecting the issues where they were previously missed.
- The practical problem is not "which patch do we apply first?" It is "which clusters, identities, and workflows still carry the risky condition?"
- Teams need a mitigation-first playbook for issues like webhook redirect behavior, DNS TOCTOU proxy bypass, and cross-namespace forwarding through Endpoints.
What changed on June 1
Kubernetes published an unusually useful post in late May about several older CVEs that remain unfixed.
The core issue was not a new disclosure. It was record quality.
According to the Kubernetes Security Response Committee, some older CVE records incorrectly included fixed version fields even though the underlying issues are architectural trade-offs with no clean code fix that preserves expected Kubernetes behavior.
So on June 1, 2026, Kubernetes corrected those records.
That matters because modern scanner pipelines trust vulnerability metadata. If the metadata changes, your scanner output changes too.
In other words, a security team can wake up to "new" Kubernetes findings that are actually older risks described more accurately than before.
Why this is not just scanner noise
When teams see old CVEs reappear, the first reflex is often to ask whether the scanner is wrong.
That is the wrong first question.
The better first question is whether the finding points to a real architectural risk that still exists in your environment.
That is the point Kubernetes is making.
These are not patch-now bugs with a neat upgrade path. They are long-lived behaviors that need administrative mitigation, access review, or configuration hardening.
So the new scanner finding may feel noisy, but the underlying signal is still useful:
- a control-plane path may still behave in a risky way
- an older permission model may still allow more than the team expects
- a legacy workflow may still depend on a broad capability nobody has reviewed recently
That turns the job into triage, not denial.
Corrected records change scanner visibility. The operator job is to map exposure and mitigations, not just hunt for a version bump.
The three unfixed risks worth separating first
The Kubernetes post analyzes three issues in detail. They should not be lumped together because the mitigation path is different for each one.
1. CVE-2020-8561: webhook redirect behavior in kube-apiserver
Kubernetes says the API server follows HTTP redirects when communicating with admission webhooks.
That means an actor who can configure an admission webhook may be able to redirect requests toward internal private networks.
Kubernetes also explains why the issue remains unfixed: tightening the behavior would break standard HTTP-client expectations used by legitimate integrations.
The recommended mitigation is administrative:
- keep API server log verbosity below 10
- set
--profiling=false
This is a good example of why a scanner finding is only the start. The responder still needs to know where webhook configuration is delegated, which clusters run that pattern, and whether the recommended controls are already in place.
2. CVE-2020-8562: DNS TOCTOU proxy bypass
This issue is a race condition in API server proxy behavior.
Kubernetes says the system can validate an IP through DNS and then resolve again for the actual connection, creating a time-of-check to time-of-use gap that can be abused to bypass restrictions.
Again, the reason it remains unfixed is not neglect. The safer behavior can break split-horizon or dynamic DNS environments that teams genuinely use.
The mitigation is operational:
- use a local DNS caching resolver such as dnsmasq
- enforce consistent responses with a minimum cache TTL
So if this finding appears, the important question is not whether a package version is stale. It is whether your control-plane DNS path is predictable enough to close the gap.
3. CVE-2021-25740: cross-namespace forwarding through Endpoints
Kubernetes also calls out the risk that users can manually specify IPs in Endpoints or EndpointSlices and steer traffic toward backends in other namespaces.
This matters because it can quietly turn a networking convenience into a trust-boundary problem.
The mitigation is RBAC and object-governance hygiene:
- restrict write access to Endpoints and EndpointSlices
- audit upgraded clusters for lingering broad grants
Kubernetes notes that the default edit and admin ClusterRoles stopped including that permission for new clusters in v1.22, but upgraded environments may still need cleanup.
That is exactly the sort of detail scanners do not resolve for you.
A practical triage sequence for platform teams
If one of these findings lands in a queue today, I would keep the response simple:
- Classify whether the CVE is patchable or architectural.
- Read the upstream mitigation guidance before opening a generic upgrade task.
- Map which clusters, control-plane paths, roles, or integrations could actually trigger the condition.
- Verify whether the recommended mitigation is already present.
- Decide whether the right next action is hardening, permission cleanup, ownership follow-up, or documented risk acceptance.
That sounds obvious, but many teams still burn hours bouncing between scanner dashboards, Jira tickets, and cluster owners before they answer the basic question:
Where are we exposed, if anywhere?
The fastest teams separate detection from diagnosis. Scanner visibility is step one, not the whole workflow.
Where teams usually get stuck
The blocker is rarely the CVE description itself.
The blocker is context:
- Which clusters still expose this path?
- Which team owns the relevant webhook, proxy, or RBAC pattern?
- Was the mitigation already applied in one environment but not another?
- Did an upgrade preserve old permissions or configuration drift?
- Which finding deserves immediate action versus a scheduled hardening review?
This is where vulnerability management starts looking a lot like incident response.
Not because every finding is an active incident, but because the team still has to assemble enough live context to choose a safe next step quickly.
Where OpsRabbit fits
OpsRabbit is useful after the finding appears.
The hard part is not opening a ticket. The hard part is connecting the alert to the environment:
- which services and clusters are involved
- who owns them
- what changed recently
- which mitigations are already visible
- which adjacent systems might be affected by a cleanup action
That is a time-to-context problem, and it is exactly the gap that turns a manageable security finding into a slow operational drain.
Final thought
I like this Kubernetes correction because it is honest.
It tells teams that not every important security issue ends with "upgrade to version X."
Sometimes the right response is better record quality, better mitigation guidance, and better operator context.
If your scanners start surfacing older Kubernetes CVEs again, do not panic and do not wave them away.
Treat them as a prompt to ask a better question:
Do we understand where this risk still exists, and are we actually handling it on purpose?
FAQs
Are these unfixed Kubernetes CVE findings just false positives?
No. Kubernetes corrected several records so scanners can now represent long-standing architectural risks more accurately. The right question is whether your environment still carries the risky condition and whether the recommended mitigations are in place.
Which Kubernetes CVEs matter most in this June 2026 record correction?
The Kubernetes post analyzes CVE-2020-8561, CVE-2020-8562, and CVE-2021-25740 in detail, and it also notes an update to CVE-2020-8554.
Sources
- Reconciling the Past: Correcting Records for Unfixed Kubernetes CVEs - Kubernetes Blog, May 26, 2026.
- CVE-2020-8561 issue reference - Kubernetes GitHub issue, referenced by Kubernetes in June 2026 guidance.
- CVE-2020-8562 issue reference - Kubernetes GitHub issue, referenced by Kubernetes in June 2026 guidance.
- CVE-2021-25740 issue reference - Kubernetes GitHub issue, referenced by Kubernetes in June 2026 guidance.
Last Updated
2026-06-28
Ready to Transform Your Operations?
Ask for a demo today. Experience how OpsRabbit can reduce your MTTR by up to 90%.