devopscodepro
Language
Productized services
Infrastructure AuditRisks, costs and quick wins — mapped in two weeks.Cloud Migration & IaCTerraform, CI/CD and a zero-downtime cutover.Monitoring-as-a-ServiceAlerting, on-call and incident response.Fractional DevOpsA senior engineer in your team, part-time.
Not sure where to start? The audit answers that.Request a quote →
server-assisted · every other tool runs in your browserAll 29 tools →
Infrastructure AuditCloud Migration & IaCMonitoring-as-a-ServiceFractional DevOps
ContactLog in
Request a quote
Theme
Language
server-assisted

Kubernetes CVEs

Enter a Kubernetes version: known CVEs with the patch that fixes them on your release line, plus support status.

advisories are matched by machine-readable version ranges, not by text search
Enter the Kubernetes version your cluster runs.
These tools show symptoms. A full infrastructure audit finds the causes — risks, cost leaks and single points of failure, mapped in two weeks.
Request a quote →

How versions are matched to advisories

Your version is matched against the machine-readable version ranges published with each GitHub Security Advisory, served through OSV. That matters: the official Kubernetes CVE feed describes affected versions only in prose, so matching it by text would produce false negatives — the one mistake a vulnerability tool must not make.

For every advisory the tool reports the fix on your own release line. Kubernetes backports each fix to every supported minor, so a 1.28 cluster needs a 1.28 patch, not the 1.31 release the advisory also lists.

Which components does this cover?

The Kubernetes core, published as k8s.io/kubernetes. Advisories for the ecosystem around it — ingress controllers, CSI drivers, operators — are filed against their own projects and are not in this data set. The page says so rather than implying full coverage.

My managed cluster reports v1.29.4-eks-abc1234. Can I use that?

Yes, paste it as is. The distribution suffix is stripped and the upstream release is used, because that is what advisories are filed against. Note that managed providers backport fixes into their own builds, so a fix may already be in even when the upstream patch number is higher.

Some advisories show no severity. Why?

They come from the Go vulnerability database, which does not always carry a CVSS rating. They are shown as unrated and still counted — a version carrying them never grades A, because unrated is not the same as harmless.

What if the advisory source is unreachable?

You get an error, never an empty list. Reporting 'no vulnerabilities found' because a lookup failed would be the most dangerous possible output for this kind of tool.

Why does support status affect the grade?

Because a release line past end-of-life receives no further security patches. Every advisory published after that date stays unfixed on your cluster no matter what you do, short of upgrading.

Related tools: K8s manifest validator, Dockerfile analyzer and SBOM viewer.