CVE-2023-6476 is a medium severity flaw in CRI-O, the Kubernetes container runtime. An experimental annotation can leave a container unconfined, so a pod may take any amount of memory or CPU, skipping the scheduler and potentially causing denial of service on the node. Apply the vendor update.
What's affected
- Product: CRI-O, as shipped in Red Hat OpenShift Container Platform 3.11, 4.13 and 4.14 and Red Hat Enterprise Linux 8, per the record product list.
- Affected: the record gives no upstream version range. See the Red Hat pages for exact builds.
- Fixed: see Red Hat errata RHSA-2024:0195 and RHSA-2024:0207 linked in the record.
- Privilege needed: the ability to create pods that carry the annotation.
The record gives a CVSS 3.1 base score of 6.5 (medium) with the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H. The CISA Known Exploited Vulnerabilities flag in the record is false. This post does not claim exploitation in the wild.
How to check if you're exposed
Check the CRI-O version on each node and compare it with the errata.
crio --version
oc get nodes -o wide
rpm -q cri-o
To see whether anything uses the annotation, search your pod specs for the experimental annotation that the Red Hat page names. Use the exact name from the Red Hat page for CVE-2023-6476 rather than guessing it.
What to do now
- List the clusters and nodes that run CRI-O.
- Apply the Red Hat errata for your release, or the upstream fix if you run community builds.
- Use admission control to reject pods carrying the unconfined annotation, and set resource limits and quotas on namespaces.
- Restrict who can create pods in shared clusters.
- Run the free in-browser dependency scan at gold.safeguard.sh/scan on any project you build that bundles this component, and keep the result next to your inventory.
Why it matters
The record maps this issue to CWE-770 (Allocation of Resources Without Limits or Throttling): A component hands out CPU, memory or similar resources without a ceiling, so one consumer can starve everything else.
The record classes the weakness as allocation of resources without limits. The scheduler places pods based on requested resources. A pod that escapes its limits can use more than it asked for, and other pods on the node lose out.
The impact is availability only, and the attacker needs the right to create pods. Multi-tenant clusters carry the most risk, since one tenant can disturb another. Namespace quotas and admission policies reduce this whether or not a given runtime bug exists.
Try it yourself
This demo shows a container image scan, useful for checking the runtime and base images behind your nodes.
Click through it at your own pace, or open it full screen.
Quick check
Can an unprivileged user exploit it?
The vector needs low privileges, which in practice means being able to create pods in the cluster.
Is data exposed?
No. The record rates the impact as availability only.
Sources
These are the references listed in the NVD record for this CVE. They were not fetched when this post was written, so confirm fixed versions in the advisory before acting.
- access.redhat.com
- access.redhat.com
- access.redhat.com
- bugzilla.redhat.com
- Gold entry for CVE-2023-6476
Last reviewed: 19 October 2026.
