some Kubernetes vulnerabilities do not have patches

There is a comforting rhythm to vulnerability management.

A scanner finds a CVE. Someone opens a ticket. You upgrade a package. The scanner goes green again.

It is not glamorous work, but at least the shape of the problem is familiar.

Today, some Kubernetes teams are going to get a reminder that security does not always work like that.

The Kubernetes Security Response Committee is correcting the records for three older CVEs on June 1, 2026. The records previously suggested that fixed versions existed. They do not. These are architectural risks that remain present across Kubernetes versions, and scanners may start reporting them in clusters where they were not reported before.

That sounds like a paperwork update.

It is also a useful test of whether your vulnerability program understands the difference between patching software and owning a system.

the scanner is not wrong

The three CVEs are not new:

• CVE-2020-8561: the API server follows redirects when calling admission webhooks
• CVE-2020-8562: a DNS time-of-check to time-of-use race can bypass API server proxy IP restrictions
• CVE-2021-25740: write access to Endpoints and EndpointSlices can be used to forward traffic across namespace boundaries

The first two are low-to-medium severity. The third is low severity. None of this is a reason to declare an incident because a dashboard changed color overnight.

But none of it should be dismissed either.

The corrected records matter because vulnerability scanners depend on version ranges. If a CVE record says a fixed version exists, the scanner may assume a newer cluster is safe. Once the record says all versions are affected, the finding appears again.

Your cluster did not suddenly become less secure on June 1.

The data describing the risk became more honest.

That is good. Slightly annoying, but good.

some features are also attack surfaces

The interesting part is why these CVEs remain unfixed.

Take the admission webhook redirect issue. The API server uses ordinary HTTP client behavior when talking to admission webhooks. Following redirects is useful for legitimate integrations. It can also let someone who can configure a webhook redirect requests toward internal networks.

Or take the DNS proxy issue. The API server validates an IP after resolving a hostname, then resolves again when making the connection. An attacker who can manipulate the answers may exploit the gap. Pinning the first resolved IP sounds obvious until you remember split-horizon DNS and dynamic environments exist for real reasons.

The endpoint issue is even more familiar. Kubernetes allows endpoint objects to refer to manually specified IP addresses because networking tools and operators rely on that flexibility. The same flexibility can be abused to point traffic somewhere a namespace owner should not be able to reach.

These are not bugs in the usual sense.

They are examples of a platform being flexible enough to create dangerous combinations.

Removing the behavior would break valid workloads. Keeping the behavior means administrators need to constrain who can use it and how the control plane resolves or records it.

upgrade is not a universal security strategy

I have seen plenty of security programs organized around a simple metric: how quickly can we close scanner findings?

That metric is useful until it becomes the whole strategy.

When every finding is treated like a package upgrade, the workflow gets weird around architectural risks. Teams either keep searching for a version that does not exist, suppress the alert without understanding it, or leave a ticket open forever so the dashboard can remind everyone that nobody knows what to do.

None of those outcomes improve security.

The better question is:

What control owns this risk now that a patch does not?

For these Kubernetes CVEs, the upstream recommendations are concrete:

• Keep API server verbosity below 10 and disable dynamic profiling with --profiling=false
• Use a local caching resolver such as dnsmasq for the API server so DNS answers remain consistent between validation and connection
• Restrict write access to Endpoints and EndpointSlices, especially on clusters upgraded from versions before Kubernetes 1.22

That last point is worth checking carefully. Newer clusters no longer grant those endpoint write permissions through the default aggregated edit and admin roles. Older clusters that were upgraded may still carry the broader permissions unless someone reconciled them.

This is the sort of small historical detail that quietly survives three platform migrations and then appears in a security review at the worst possible time.

configuration is part of the security boundary

There is a broader lesson here for platform teams.

We often talk about Kubernetes security as if it lives in release notes: stay supported, patch quickly, scan images, rotate credentials, repeat.

That work matters. But a Kubernetes cluster is not secure merely because it runs a recent version.

The API server flags matter.

The DNS path from the control plane matters.

The permissions inherited by roles created years ago matter.

The list of people and controllers allowed to write networking objects matters.

The dangerous part is that configuration risks rarely have the satisfying closure of an upgrade. You cannot point to a new version number and move on. You need an explicit control, a test for that control, and an owner who notices when the environment drifts.

This is less exciting than patching a zero-day.

It is also most of the job.

what i would do today

If these findings appear in your scanner, do not start with a blanket exception.

Start by separating the inventory from the mitigation:

1. Confirm which clusters are reporting the corrected CVEs.
2. Check API server verbosity and profiling configuration.
3. Review how control plane DNS resolution works, particularly in managed environments where you may need the provider's guidance.
4. Audit who can create admission webhook configurations.
5. Audit write access to Endpoints and EndpointSlices, including inherited and aggregated RBAC roles.
6. Record the mitigation as a control with an owner and a periodic check.

For managed Kubernetes, some controls may sit with the cloud provider. That is not a reason to ignore the finding. It is a reason to document the responsibility boundary clearly and verify what the provider actually guarantees.

Also, test changes in a non-production cluster. These risks remain unfixed precisely because the obvious fixes can break legitimate behavior. A security improvement that takes down internal networking is still an incident.

the punchline

The Kubernetes project is doing the right thing here.

Correcting old CVE records may create scanner noise, but inaccurate green dashboards are worse. Mature vulnerability data should tell you when a risk persists, even when the answer is not a neat upgrade command.

Some security findings are patch tickets.

Some are architecture decisions with mitigations.

The important thing is knowing which one you are looking at before you close the alert.

references

• Kubernetes Blog: Reconciling the Past: Correcting Records for Unfixed Kubernetes CVEs
• Kubernetes Documentation: Role-based access control good practices