CVE landscape and known issues — staying current

Kubernetes is a fast-moving target. Every minor release brings feature work, dependency updates, and — frequently — security fixes. A cluster that does not upgrade is, by definition, accumulating vulnerabilities. This lesson covers the CVE cadence, the historic issues that shaped the platform, and the discipline of staying current.

The release cadence

Kubernetes ships three minor releases per year (roughly every four months). Each minor release is supported for ~14 months with security backports. The current support window for 1.34.x runs from its GA date through approximately three months after 1.37’s GA — roughly August 2026 through late 2027.

gantt
    title Kubernetes release and support windows
    dateFormat YYYY-MM
    axisFormat %b %Y
    section Kubernetes
    1.32 (legacy)         :done, 2024-12, 2026-04
    1.33 (supported)      :active, 2025-04, 2026-08
    1.34 (current)        :active, 2025-08, 2027-01
    1.35 (next)           :2026-01, 2027-05
    1.36 (future)         :2026-05, 2027-09

A cluster running 1.30 or earlier is past the support window and receives no security backports. The first control of CVE management is stay within the supported window.

The historic CVEs

The list of Kubernetes CVEs is short relative to the number of features shipped, but each one is a story:

The lesson from each is the same: stay current. The patch is always in the next supported minor; the cluster that did not upgrade is the one that fell.

The CVE feed

The Kubernetes project publishes CVEs in three places:

1. GitHub Security Advisories at github.com/kubernetes/kubernetes/security/advisories — the canonical feed. Subscribe to the Watch for the repo.
2. kubernetes.io/docs/reference/issues-security/security/ — the human-readable index.
3. Distribution feeds — GKE, EKS, AKS each publish their own CVE feed because they backport patches on their own cadence. A GKE cluster receives a patch within days of upstream; a kubeadm cluster waits for the operator.

# Verify the running version
kubectl version

# Check for advisories against this version
# Visit https://github.com/kubernetes/kubernetes/security/advisories?query=published%3A%3E2026-01-01

Staying current in production

The right cadence for production is:

• Patch releases (x.y.z): apply within 2 weeks of release. These are security and bug fixes; the API surface does not change.
• Minor releases (x.y): apply within 3 months of release. API deprecations and removals may affect workloads.
• Major (the third number in semver terms, but Kubernetes calls these “minor”): the same cadence.

The most common production failure is patch avoidance. Operators wait for the next minor before applying patches because they conflate the two release types. The result is a cluster that runs 1.30.0 in production when 1.30.7 exists.

Production failure modes

1. Conflating the cadences. “We apply Kubernetes upgrades once a year” is a statement that the cluster misses every patch and most minors. The two cadences are independent.
2. No CVE subscription. A cluster whose security team has not subscribed to the Kubernetes CVE feed discovers CVEs only when an incident happens.
3. Skipping minors. A cluster that jumps from 1.31 to 1.34 has three minors’ worth of API removals to absorb in one shot. The right discipline is one minor per quarter.

Cross-course references

• The Linux course covers kernel CVEs — the same cadence discipline applies.
• The Observability course covers the alerting that detects when an unpatched CVE is being exploited.

Quiz

Production discipline

A defensible cluster subscribes to the Kubernetes CVE feed, stays within the supported version window, applies patches within 2 weeks, and plans minor upgrades within 3 months. The security team’s quarterly review reports the current version, the latest available patch, the gap, and the upgrade plan. The platform team’s runbook documents the patch procedure with drain, cordon, PDB-aware batching, and a rollback path for the rare regression. CVE management is not a project; it is a cadence.