Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
11 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact Patches 1.31.1, 1.30.6, 1.29.8 Workarounds set enablecriusupport = false References Are there any links users can visit to find out more?
Recommended action: Upgrade to 1.31.3, 1.30.8 or 1.29.11 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A malicious container can affect the host by taking advantage of code cri-o added to show the container mounts on the host. A workload built from this Dockerfile: and this container config: and this sandbox config will create a file on host /host/mtab Patches 1.30.1, 1.29.5, 1.28.7 Workarounds Unfortunately not References Are there any links users can visit to find out more?
Recommended action: Upgrade to 1.30.1, 1.29.5 or 1.28.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact On CRI-O, it looks like an arbitrary systemd property can be injected via a Pod annotation: This means that any user who can create a pod with an arbitrary annotation may perform an arbitrary action on the host system. Tested with CRI-O v1.24 on minikube. I didn't test the latest v1.29 because it is incompatible with minikube: https://github.com/kubernetes/minikube/pull/18367 Thanks to Cédric Clerget (GitHub ID @cclerget) for finding out that CRI-O just passes pod annotations to OCI annotations: https://github.com/opencontainers/runc/pull/3923#discussionr1532292536 CRI-O has to filter out annotations that have the prefix "org.systemd.property." See also: - https://github.com/opencontainers/runtime-spec/blob/main/features.md#unsafe-annotations-in-configjson - https://github.com/opencontainers/runc/pull/4217 Workarounds Unfortunately, the only workarounds would involve an external mutating webhook to disallow these annotations References
Recommended action: Upgrade to 1.29.4, 1.28.6 or 1.27.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 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 . 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…
Recommended action: Upgrade to 1.29.1, 1.28.3 or 1.27.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact It is possible to craft an environment variable with newlines to add entries to a container's /etc/passwd. It is possible to circumvent admission validation of username/UID by adding such an entry. Note: because the pod author is in control of the container's /etc/passwd, this is not considered a new risk factor. However, this advisory is being opened for transparency and as a way of tracking fixes. Patches 1.26.0 will have the fix. More patches will be posted as they're available. Workarounds Additional security controls like SELinux should prevent any damage a container is able to do with root on the host. Using SELinux is recommended because this class of attack is already possible by manually editing the container's /etc/passwd References
Recommended action: Upgrade to 1.26.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Incorrect handling of the supplementary groups in the CRI-O container engine might lead to sensitive information disclosure or possible data modification if an attacker has direct access to the affected container where supplementary groups are used to set access permissions and is able to execute a binary code in that container.
Recommended action: Upgrade to 1.25.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An ExecSync request runs a command in a container and returns the output to the Kubelet. It is used for readiness and liveness probes within a pod. The way CRI-O runs ExecSync commands is through conmon. CRI-O asks conmon to start the process, and conmon writes the output to disk. CRI-O then reads the output and returns it to the Kubelet. If the output of the command is large enough, it is possible to exhaust the memory (or disk usage) of the node. The following deployment is an example yaml file that will output around 8GB of ‘A’ characters, which would be written to disk by conmon and read by CRI-O. Impact It is possible for the node to be exhausted of memory or disk space, depending on the node the command is being run on. What is further problematic is that the memory and disk usage aren't attributed to the container, as this file and its processing are implementation details of CRI-O. The consequence of the exhaustion is that other services on the node, e.g. other…
Recommended action: Upgrade to 1.24.1, 1.23.3 or 1.22.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A bug was found in CRI-O where containers were incorrectly started with non-empty inheritable Linux process capabilities, creating an atypical Linux environment and enabling programs with inheritable file capabilities to elevate those capabilities to the permitted set during execve(2). Normally, when executable programs have specified permitted file capabilities, otherwise unprivileged users and processes can execute those programs and gain the specified file capabilities up to the bounding set. Due to this bug, containers which included executable programs with inheritable file capabilities allowed otherwise unprivileged users and processes to additionally gain these inheritable file capabilities up to the container's bounding set. Containers which use Linux users and groups to perform privilege separation inside the container are most directly impacted. This bug did not affect the container security sandbox as the inheritable set never contained more capabilities than were…
Recommended action: Upgrade to 1.24.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
1.23.21.22.31.21.61.19.61.20.7· Vendor fix available
Issue
Impact A flaw introduced in CRI-O version 1.19 which an attacker can use to bypass the safeguards and set arbitrary kernel parameters on the host. As a result, anyone with rights to deploy a pod on a Kubernetes cluster that uses the CRI-O runtime can abuse the kernel.corepattern kernel parameter to achieve container escape and arbitrary code execution as root on any node in the cluster. Patches The patches will be present in 1.19.6, 1.20.7, 1.21.6, 1.22.3, 1.23.2, 1.24.0 Workarounds - Users can set managenslifecycle to false, which causes the sysctls to be configured by the OCI runtime, which typically filter these cases. This option is available in 1.20 and 1.19. Newer versions don't have this option. - An admission webhook could be created to deny pods that specify a + in the sysctl value of a pod. - A PodSecurityPolicy [deprecated] could be created, specifying all sysctls as forbidden like so: However, this option will not work if any sysctls are required by any pods in the…
Recommended action: Upgrade to 1.23.2, 1.22.3, 1.21.6 or 2 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
1.21.51.23.11.22.21.19.51.20.6· Vendor fix available
Issue
Impact Before setting the sysctls for a pod, the pods namespaces must be unshared (created). However, in cases where the pod is using a host network or IPC namespace, a bug in CRI-O caused the namespace creating tool pinns to configure the sysctls of the host. This allows a malicious user to set sysctls on the host, assuming they have access to hostNetwork and hostIPC. Any CRI-O cluster after CRI-O 1.18 that drops the infra container 1.22 and 1.23 clusters drop infra container by default, and are thus vulnerable by default. Patches CRI-O versions 1.24.0, 1.23.1, 1.22.2, 1.21.5, 1.20.6, 1.19.5 all have the patches. Workarounds Users can set managenslifecycle to false, which causes the sysctls to be configured by the OCI runtime, which typically filter these cases. This option is available in 1.20 and 1.19. Newer versions don't have this option. An admission webhook could also be created to deny pods that use host IPC or network namespaces and also attempt to configure sysctls related…
Recommended action: Upgrade to 1.23.1, 1.22.2, 1.21.5 or 2 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An incorrect sysctls validation vulnerability was found in CRI-O 1.18 and earlier. The sysctls from the list of "safe" sysctls specified for the cluster will be applied to the host if an attacker is able to create a pod with a hostIPC and hostNetwork kernel namespace.
Recommended action: Upgrade to 1.23.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.