CVE-2023-6476
highpriority · track · 30EPSS 0.009 · 58 %ileDEEURUUSEPSS · scored 2026-10-27
A flaw was found in CRI-O that involves an experimental annotation leading to a container being unconfined. This may allow a pod to specify and get any amount of memory/cpu, circumventing the kubernetes scheduler and potentially resulting in a denial of service in the node.
cvss
Technical severity, 0–10. One row per scoring source.
base score 0–10 · higher = more severe · hover a vector to decode⚠ sources disagree · medium–high · 6.5–7.5
ssvc
A stakeholder decision — act, attend, or track — from exploitation and impact.
weaknesses
The CWE weakness classes this flaw belongs to.
affected products (30)
Products and version ranges known to be affected.
- Red Hat Red Hat OpenShift Container Platform 4.13< 0:1.26.4-6.1.rhaos4.13.git9eb9cf3.el9enisa_euvdEU
advisories (3)
Vendor and ecosystem advisories describing this.
- WID-SEC-W-2024-0137Red Hat OpenShift Container Platform: Mehrere Schwachstellen ermöglichen Denial of ServiceDeutsch2024-01-17csaf · cert_bundDE
Ein entfernter, anonymer oder authentisierter Angreifer kann mehrere Schwachstellen in Red Hat OpenShift Container Platform ausnutzen, um einen Denial of Service Angriff durchzuführen.
- GHSA-p4rx-7wvg-fwrcCRI-O's pods can break out of resource confinement on cgroupv22024-01-10ghsa · osvUS
### Impact _What kind of vulnerability is it? Who is impacted?_ All versions of CRI-O running on cgroupv2 nodes. Unchecked access to an experimental annotation allows a container to be unconfined. Back in 2021, [support was added](https://github.com/cri-o/cri-o/pull/4479) to support an experimental annotation that allows a user to request special resources in cgroupv2. It was supposed to be gated by an experimental annotation: `io.kubernetes.cri-o.UnifiedCgroup`, which was supposed to be filtered from the [list of allowed annotations](https://github.com/cri-o/cri-o/blob/main/pkg/config/workloads.go#L103-L107) . However, there is a bug in this code which allows any user to specify this annotation, regardless of whether it's enabled on the node. The consequences of this are a pod can specify any amount of memory/cpu and get it, circumventing the kubernetes scheduler, and potentially be able to DOS a node. ### Patches _Has the problem been patched? What versions should users upgrade to?_ 1.29.1, 1.28.3, 1.27.3 ### Workarounds _Is there a way for users to fix or remediate the vulnerability without upgrading?_ use cgroupv1 ### References _Are there any links users can visit to find out more?_
- GO-2024-2458CRI-O's pods can break out of resource confinement on cgroupv2 in github.com/cri-o/cri-o2024-06-28vendor · osvUS
CRI-O's pods can break out of resource confinement on cgroupv2 in github.com/cri-o/cri-o
also known as (6)
Other names and identifiers for this entity.
sources
Which sources assert this record, and when.
references (14)
External citations — patches, advisories, analysis.
- https://access.redhat.com/security/cve/CVE-2023-6476cnnvd
- https://access.redhat.com/security/cve/cve-2023-6476cnnvd
- https://bugzilla.redhat.com/show_bug.cgi?id=2253994cnnvd
- https://cxsecurity.com/cveshow/CVE-2023-6476/cnnvd
- https://packetstormsecurity.com/files/176595/Red-Hat-Security-Advisory-2024-0207-03.htmlcnnvd
- https://www.auscert.org.au/bulletins/ESB-2024.0363cnnvd
- https://access.redhat.com/errata/RHSA-2024:0195enisa_euvd
- https://access.redhat.com/errata/RHSA-2024:0207enisa_euvd
Attackers weaponise vulnerabilities like this against internet-exposed services. See what is exposed on your perimeter with a free passive scan.
Free scan