CVE-2024-3154: CRI-O Container Runtime RCE Vulnerability

CVE-2024-3154 Overview

CVE-2024-3154 is a command injection flaw in CRI-O, the OCI-compliant container runtime used by Kubernetes. The vulnerability allows an authenticated user who can create pods to inject arbitrary systemd properties through a Pod annotation. Because CRI-O passes annotation values into systemd unit configuration without proper sanitization, an attacker can execute arbitrary actions on the underlying host. The flaw is tracked under CWE-77: Improper Neutralization of Special Elements used in a Command and affects multi-tenant Kubernetes and OpenShift environments where pod creation rights are delegated.

Critical Impact
Any principal with permission to create a pod with a custom annotation can execute arbitrary commands on the container host, leading to full node compromise and lateral movement across the cluster.

Affected Products

CRI-O container runtime (versions prior to the patched releases referenced in GHSA-2cgq-h8xw-2v5j)
Red Hat OpenShift Container Platform (see Red Hat CVE-2024-3154 Details)
Kubernetes clusters using CRI-O with systemd cgroup driver

Discovery Timeline

2024-04-26 - CVE-2024-3154 published to the National Vulnerability Database
2024-05-08 - Red Hat releases RHSA-2024:2669 and RHSA-2024:2672
2024-05-15 - Additional fix shipped in RHSA-2024:2784
2024-05-30 - Follow-up advisory RHSA-2024:3496 published
2026-04-15 - Last updated in the NVD database

Technical Details for CVE-2024-3154

Vulnerability Analysis

CRI-O forwards Pod-level annotations into the OCI runtime configuration when launching containers. When the systemd cgroup driver is in use, certain annotation values are translated into systemd unit properties via the runc and systemd Go bindings. The runtime did not enforce a strict allow-list on which properties could be set, nor did it sanitize values forwarded to systemd.

An attacker supplies an annotation that maps to a sensitive systemd directive such as ExecStartPre or ExecStartPost. The injected directive runs in the context of the host systemd instance, which executes as root. Successful exploitation yields arbitrary command execution outside the container boundary.

This class of issue is documented in the OCI runtime-spec unsafe-annotations discussion, which motivated the upstream fix in runc Pull Request #4217.

Root Cause

The root cause is improper neutralization of special elements in command-like input ([CWE-77]). CRI-O accepted annotation strings and translated them directly into systemd properties without validating that the resulting property was safe to set on the host. The trust boundary between unprivileged pod specifications and privileged host services was not enforced.

Attack Vector

The attacker requires the ability to create a pod with arbitrary annotations - a privilege commonly held by namespace administrators, CI/CD service accounts, and tenants in shared clusters. The attacker crafts a Pod manifest containing a malicious annotation key recognized by CRI-O. When the kubelet schedules the pod, CRI-O writes the attacker-controlled value into the systemd scope configuration. The host systemd executes the embedded command as root, breaking container isolation.

No memory corruption, network access, or pre-existing host access is required beyond Kubernetes API authentication. See the Red Hat Bug Report #2272532 for additional context.

Detection Methods for CVE-2024-3154

Indicators of Compromise

Pod manifests containing annotations with systemd-related directives such as ExecStart, ExecStartPre, ExecStartPost, or property names with embedded shell metacharacters
Unexpected child processes of systemd (PID 1) on Kubernetes worker nodes that do not correspond to known containers or system services
Audit log entries from kube-apiserver showing pod create requests with unusual or oversized annotation values from non-administrative service accounts
Modified systemd transient unit files under /run/systemd/transient/ referencing crio-scoped names with unexpected Exec* directives

Detection Strategies

Ingest Kubernetes API audit logs and alert on create pod events where annotation keys or values contain systemd property names or shell metacharacters such as ;, |, &&, or newline characters
Monitor process creation on worker nodes for processes whose parent is systemd but whose executable path falls outside expected system binaries
Correlate CRI-O logs (journalctl -u crio) with kubelet pod creation events to identify annotations that triggered unexpected systemd activity
Deploy admission controllers such as OPA Gatekeeper or Kyverno with policies rejecting pods that carry unsanctioned annotation keys

Monitoring Recommendations

Enable Kubernetes audit logging at the Metadata level or higher for all pod create and update operations
Forward CRI-O, kubelet, and systemd-journald logs to a centralized analytics platform for retention and correlation
Baseline annotation key usage per namespace and alert on new or anomalous annotation keys appearing in production workloads
Track CRI-O package versions across the fleet and alert on nodes running pre-patch releases

How to Mitigate CVE-2024-3154

Immediate Actions Required

Upgrade CRI-O to a patched release as specified in the GitHub Security Advisory GHSA-2cgq-h8xw-2v5j
For Red Hat OpenShift, apply the cluster updates referenced in RHSA-2024:2669, RHSA-2024:2672, RHSA-2024:2784, and RHSA-2024:3496
Restrict pod creation privileges via Kubernetes RBAC, removing broad create pods grants from non-administrative service accounts
Audit existing namespaces for pods carrying unexpected annotations and quarantine any suspicious workloads

Patch Information

Red Hat has released errata covering OpenShift Container Platform versions impacted by this flaw. The upstream fix is documented in GHSA-2cgq-h8xw-2v5j and the related runc Pull Request #4217, which constrains which annotations are honored by the runtime. Apply CRI-O updates on every worker node and drain or reboot nodes to ensure the new runtime binary is in use.

Workarounds

Deploy a validating admission webhook that rejects Pod specifications containing annotation keys not on an explicit allow-list
Use Pod Security Admission and namespace-level RBAC to limit which identities can submit pod manifests with custom annotations
Where feasible, switch CRI-O to the cgroupfs driver to reduce reliance on systemd property translation, while validating workload compatibility first
Apply OPA Gatekeeper or Kyverno constraints that block annotations matching *systemd* patterns or containing shell metacharacters

bash

# Example Kyverno policy snippet to block suspicious annotations
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: block-systemd-annotation-injection
spec:
  validationFailureAction: Enforce
  rules:
    - name: deny-systemd-annotations
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: "Annotations referencing systemd properties are not allowed."
        deny:
          conditions:
            any:
              - key: "{{ request.object.metadata.annotations.keys(@)[] }}"
                operator: AnyIn
                value:
                  - "*ExecStart*"
                  - "*systemd*"