The Kubernetes project publishes an official CVE feed, in JSON and RSS, listing issues announced by its Security Response Committee. Subscribe to one of those two URLs, route new entries to your platform team, and check each against your cluster version and the add-ons you run.
What the feed is
The Kubernetes documentation describes the feed as a community maintained list of official CVEs announced by the Kubernetes Security Response Committee. It has carried the Beta feature state since Kubernetes v1.27, and the page shows a "last updated" timestamp so you can tell whether the list is current.
The two machine readable endpoints are:
- JSON:
https://k8s.io/docs/reference/issues-security/official-cve-feed/index.json - RSS:
https://k8s.io/docs/reference/issues-security/official-cve-feed/feed.xml
Each row carries a CVE ID, a one line summary, and the link to the GitHub issue that tracks it.
Why it is wider than the core
When you read the list, you will see that it is not only about the control plane. Entries name ingress controllers, storage drivers such as CSI drivers, the kubectl client, Windows node behavior, a C# client library and image build tooling. An advisory for a CSI driver matters only if you installed that driver. An advisory for a client matters on the machines where people run it.
That is the main reason to read the feed instead of relying on a version number. A cluster at a patched Kubernetes release can still run a vulnerable add-on.
Steps to put it to work
- Add the RSS URL to the feed reader or chat channel your platform team already watches. If you prefer code, fetch the JSON on a schedule and compare it with the last copy.
- List what you run: Kubernetes minor version, node operating systems, ingress controller, storage drivers, admission controllers, and the kubectl version pinned in CI.
- For each new entry, ask which component it names and whether you run it.
- If you do, find the fixed version in the linked GitHub issue and open a ticket with an owner and a date.
- If you do not, write one line saying so and close it. A recorded "not affected" saves the next person from repeating the check.
| Entry names | Ask yourself | Typical action |
|---|---|---|
| Core component | Is my minor version in the affected range? | Upgrade or apply the stated mitigation |
| Ingress controller | Do I run it, and which version? | Upgrade the controller, review annotations |
| Storage driver | Is this driver installed in any cluster? | Upgrade the driver, check mounts |
| Client tool | Where does it run (laptops, CI)? | Update the pinned client |
| Windows node issue | Do I have Windows nodes? | Patch or close as not affected |
Pitfalls
The feed tells you that an issue exists. It does not tell you whether your configuration is exposed, so you still need the details in the linked issue. Also note that managed Kubernetes services patch some components on their own schedule, so check your provider's notes before assuming you must act on the control plane.
Finally, treat the "last updated" stamp as a health check. If your poller has not seen a change in a long time, confirm the fetch is still working.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a new advisory is matched to components you already inventoried.
Where Safeguard fits
Safeguard's asset discovery and SBOM and dependency scanning give you the inventory that step 2 needs, and you can run a free scan at https://gold.safeguard.sh/scan.
Quick check
Is the Kubernetes CVE feed the same as the NVD?
No. It is a list maintained for official announcements from the Kubernetes Security Response Committee. The NVD is a separate, broader database.
Do I need to act on every entry?
No. Act on entries that name a component and version you run. Record the rest as not affected.
Sources
- Official CVE Feed, Kubernetes documentation, fetched 19 October 2026.
Last reviewed: 19 October 2026.
