The record changes, not the vulnerability
The Kubernetes CVE records for CVE-2020-8561, CVE-2020-8562, and CVE-2021-25740 were corrected on 1 June 2026 so they show all versions as affected. Earlier metadata had fixed-version fields in places where there was no upstream fix. That sort of mistake is easy to miss until someone generates the machine-readable vulnerability data and notices the ranges do not line up.
That matters because scanners do not read intent. They read version ranges from CVE and OSV files, then mark a package or cluster version as affected or not affected. If the record says a version is fixed, a scanner can go quiet even when the behaviour is still present. When the record is later corrected, the same scanner starts lighting up again. Same cluster, different paperwork.
OSV files exposed the bad fixed-version fields
The discrepancy showed up while generating official OSV files. That is the unglamorous part of vulnerability management: the file format is often where mistakes become visible, because it forces the version ranges into something a tool can compare without guessing.
For these Kubernetes CVE records, the corrected OSV data is the point where the broken fixed-version fields stop hiding the issue. The scanner result changes because the metadata changes, not because the cluster changed. If a tool keys off the record, it will follow that correction exactly.
Scanner behaviour follows the metadata, not the patch notes
Vulnerability scanners are only as honest as the version data they ingest. They do not inspect whether a cluster has a risky redirect path, a DNS race, or loose endpoint permissions. They ask whether the running version matches the affected range.
That creates two ugly failure modes. One is a false negative when bad fixed tags make the issue look resolved. The other is a sudden flood of findings after the metadata is repaired, which looks like a new incident if nobody knows the records were wrong in the first place.
The issues stay open because the behaviour is architectural
These CVEs are not waiting on a normal patch cycle. The underlying behaviour is baked into how the components work, so the fix is usually a boundary change, a restriction, or a careful setting rather than a new binary.
kube-apiserver redirect handling and DNS resolution
One case involves kube-apiserver following HTTP redirects for admission webhook requests. A redirect can send the API server towards a private network target if the webhook configuration allows it. That is why AdmissionWebhookConfiguration matters here: the webhook path is part of the attack surface, not just a plumbing detail.
Another piece is the API server proxy and DNS resolution. The proxy validates DNS, then resolves again before connecting. That leaves room for a DNS time-of-check to time-of-use race, where the name looked harmless at validation time and points somewhere else when the connection is made. Pinning a resolved IP sounds neat until split-horizon DNS or changing backend addresses turn it into a nuisance. Kubernetes does not get to pretend the network is static just because a scanner would prefer it.
The practical controls are dull, which is usually a sign they are real. Keep API server log verbosity below 10, set --v to less than 10, and disable profiling with --profiling=false. Using a local DNS caching resolver such as dnsmasq for kube-apiserver helps when DNS answers need to stay consistent long enough for the server to stop tripping over them. dnsmasq min-cache-ttl can also reduce churn in the answer set.
EndpointSlice, manual backends, and RBAC drift
The other issue set sits around Endpoints and EndpointSlice. Manual backend IP specification is allowed, which means traffic can be pointed at places that do not match the neat mental model of one service, one backend, one namespace. That is useful for some setups and awkward for security reviews.
Write access to Endpoints and EndpointSlice is where the drift tends to show up. Broad roles that still have those permissions can quietly keep shaping traffic after an upgrade. Since Kubernetes 1.22, the default edit and admin ClusterRoles no longer include those permissions, but older clusters often keep custom or aggregated roles that were never cleaned up.
The specific mess to look for is system:aggregate-to-edit. If a cluster was upgraded from an older release, it is worth checking whether that aggregated role still grants Endpoints write access. kubectl auth reconcile can strip those permissions back out when the cluster uses RBAC authorisation mode. That is not glamorous, but it stops a stale permission from becoming a routing primitive.
What to check in a cluster before you trust the scan
A clean scanner result does not mean much if the cluster still accepts the risky behaviour. The first check is whether the API server and webhook settings are tightened enough that redirect and DNS tricks have nowhere useful to land.
Tighten API server flags and webhook exposure
Start with the boring flags. Keep --v below 10 and set --profiling=false. Review any webhook configuration that allows redirects or exposes webhook endpoints to wider network paths than necessary. AdmissionWebhookConfiguration should not be treated as a harmless control plane note if it can steer API server traffic.
If the API server is depending on ordinary DNS lookups for webhooks or proxy targets, use a local caching resolver and make the answer stable enough to avoid the race. dnsmasq is the common example here because it can provide a consistent cached answer for the server process without pretending the rest of the cluster has fixed addresses forever.
Reconcile Endpoints permissions after upgrades
After an upgrade, check who can write Endpoints and EndpointSlice. The risky pattern is old RBAC still in place because nothing complained during the upgrade. Scanner output will not catch that by itself. A version check only tells you what release is running, not whether some role can quietly change service backends.
Run RBAC reconciliation against the upgraded cluster, then inspect system:aggregate-to-edit and any custom roles that inherited broader permissions than they should have kept. If the cluster uses RBAC authorisation mode, kubectl auth reconcile gives a way to remove the stale write access rather than hand-editing role objects and hoping nothing re-adds them later.
The result is not perfect certainty, just less nonsense in the scan results. That is usually the best you get with Kubernetes CVE records: version data, runtime behaviour, and access control all have to agree, and one of them is always a bit behind.
