CVE-2022-0811, publicly disclosed by CrowdStrike's cloud security research team as "cr8escape," is a high-severity vulnerability in CRI-O, the lightweight Kubernetes container runtime used by default in Red Hat OpenShift and available as an alternative to containerd/Docker across many production clusters. The flaw lets an attacker who can create or modify a pod specification — a capability that is often granted to ordinary namespace users in multi-tenant environments — inject an unsanitized sysctl value into a container's configuration and use it to execute arbitrary code on the underlying Kubernetes node. In practice, that means a single malicious or compromised pod can break out of its container boundary and gain control of the host, turning a namespace-scoped privilege into a full container escape.
Why CVE-2022-0811 Matters for Kubernetes Runtimes
Kubernetes allows pod authors to set certain sysctls through a pod's securityContext so that workloads can tune kernel behavior — for example, network buffer sizes — without needing a privileged container. To keep this feature safe, Kubernetes maintains an allowlist of "safe" sysctls that any pod can set, while "unsafe" sysctls are only permitted on nodes where a cluster administrator has explicitly opted in via the kubelet's --allowed-unsafe-sysctls flag.
CRI-O was supposed to enforce that same safe/unsafe distinction before applying sysctl values to a container. CVE-2022-0811 exists because CRI-O did not adequately validate the sysctl list it received before configuring the container's kernel namespace settings. That gap allowed an attacker to set kernel.core_pattern, a sysctl that controls how the Linux kernel handles core dumps when a process crashes. By pointing core_pattern at a pipe that runs an attacker-controlled binary, the attacker could trigger a crash inside the container and have the kernel execute their payload — with the elevated privileges available to the process handling the core dump — outside the container's intended isolation boundary. The result is arbitrary code execution on the host node, effectively a complete sysctl injection container escape with no requirement for the pod itself to run as a privileged container.
This is what makes cr8escape distinct from many other container-breakout bugs: it did not rely on a misconfigured privileged pod, a mounted host path, or a vulnerable kernel module. It relied purely on CRI-O trusting sysctl input it should have rejected, which meant clusters that believed they were following Kubernetes hardening best practices (no privileged pods, no hostPath mounts, no CAP_SYS_ADMIN) were still exposed if they were running an affected version of CRI-O.
Affected Versions and Components
- Component: CRI-O, the CRI-compliant Kubernetes container runtime (not Docker or containerd, and not Kubernetes itself).
- Affected versions: CRI-O releases from the 1.19 branch onward, prior to the patched releases below.
- Fixed versions: CRI-O 1.19.6, 1.20.7, 1.21.6, 1.22.3, and 1.23.2 all contain the fix, backported across the actively maintained release branches at the time of disclosure.
- Downstream impact: Any Kubernetes distribution or managed offering that shipped CRI-O as its runtime — most notably Red Hat OpenShift Container Platform, which uses CRI-O by default — was potentially affected until it consumed one of the patched CRI-O builds. Clusters using containerd or Docker as the container runtime interface were not affected by this specific CVE, since the vulnerable code path is unique to CRI-O's sysctl handling.
CVSS Severity and Exploitability Context
CVE-2022-0811 carries a CVSS v3.1 base score of 8.8 (High), reflecting a vector where the attack requires only local (in-cluster) access and low privileges, no user interaction, and results in a complete compromise of confidentiality, integrity, and availability once the host is reached (AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H). The "low privilege" requirement is the important detail: an attacker doesn't need cluster-admin rights, just the ability to schedule a pod with a custom securityContext.sysctls entry, which is a permission many teams grant to developers or CI pipelines without a second thought.
As of this writing, CVE-2022-0811 is not listed in CISA's Known Exploited Vulnerabilities (KEV) catalog, and there have been no widely reported cases of active exploitation in the wild. That said, absence from KEV should not be read as "safe to ignore" — proof-of-concept exploitation was demonstrated publicly by the discovering researchers at disclosure time, and the underlying technique (abusing core_pattern for privilege escalation) is a well-understood Linux exploitation primitive that is trivial to weaponize once a foothold like this exists. EPSS-style exploitation-probability scoring for this CVE has stayed relatively low since disclosure, consistent with the lack of confirmed in-the-wild campaigns, but any organization still running an unpatched, internet-facing, multi-tenant CRI-O cluster should treat this as an urgent gap rather than a theoretical one.
Disclosure Timeline
- CrowdStrike's Cloud Security research team identified the sysctl validation gap in CRI-O and reported it through coordinated disclosure to the CRI-O maintainers.
- The CRI-O project shipped patched releases (1.19.6, 1.20.7, 1.21.6, 1.22.3, 1.23.2) addressing the flaw ahead of public disclosure.
- On March 15, 2022, CrowdStrike published its research under the name "cr8escape," and CVE-2022-0811 was made public alongside it, giving defenders the technical detail needed to assess exposure and confirm remediation.
- Downstream distributions, including Red Hat OpenShift, followed with their own advisories and rebuilt images incorporating the upstream CRI-O fix.
Remediation Steps
- Identify your runtime. Confirm whether any node pool or cluster in your environment uses CRI-O as the container runtime (check
kubectl get nodes -o widefor theCONTAINER-RUNTIMEcolumn, or inspect/etc/crio/crio.confon nodes). Clusters running containerd or Docker are not affected by this specific flaw. - Check your CRI-O version. Run
crio --versionon affected nodes and compare against the fixed releases: 1.19.6, 1.20.7, 1.21.6, 1.22.3, or 1.23.2 (or later within each branch). - Patch immediately. Upgrade CRI-O to a fixed version on every node. If you run OpenShift, apply the vendor-provided errata/advisory that bundles the patched CRI-O build rather than patching CRI-O in isolation.
- Restrict sysctl permissions in the meantime. Until patched, use Pod Security Admission (or the older PodSecurityPolicy, where still in use) and admission controllers like OPA/Gatekeeper or Kyverno to block or tightly allowlist which sysctls, if any, pods are permitted to set. Do not rely solely on Kubernetes' built-in "safe sysctl" list if the underlying runtime doesn't enforce it correctly.
- Audit for signs of exploitation. Review audit logs and pod events for unexpected
securityContext.sysctlsentries, particularly any referencingkernel.core_pattern, and check node-level process history for anomalous binaries executed around the time of pod crashes. - Re-verify after upgrade. Confirm the fix by attempting to set an unsafe sysctl (in a controlled test namespace) and validating that CRI-O rejects it as expected, rather than trusting the version string alone.
How Safeguard Helps
Vulnerabilities like CVE-2022-0811 illustrate why supply chain visibility has to extend past application dependencies and into the infrastructure components — container runtimes, orchestrators, and the images that carry them — that actually execute your workloads. Safeguard continuously inventories the software composition of your Kubernetes clusters and CI/CD pipelines, including runtime components like CRI-O, so that a disclosure like cr8escape doesn't require a manual, cluster-by-cluster scramble to figure out what's exposed.
Concretely, Safeguard:
- Maps runtime and node-level SBOMs so you can immediately answer "which clusters run CRI-O, and which version?" the moment a CVE like this drops, instead of days later.
- Flags exploitable configuration paths, such as pods or namespaces permitted to set custom sysctls, correlating policy gaps with known container escape techniques rather than just listing CVEs in isolation.
- Prioritizes by real-world risk, weighing CVSS severity, KEV status, and exploitation signals together so teams patch the CRI-O nodes that matter most first, rather than treating every finding as equally urgent.
- Tracks remediation to closure, confirming that patched CRI-O versions actually reach every affected node — including managed and hybrid environments — and surfacing drift if new nodes are provisioned from stale, vulnerable images.
CVE-2022-0811 is a reminder that container isolation is only as strong as the runtime enforcing it. Safeguard's job is to make sure that when the next cr8escape-style flaw surfaces in the layer beneath your applications, you already know exactly where you stand.