containerd CRI plugin mount escape (CVE-2022-23648)

Containerd's Container Runtime Interface (CRI) plugin shipped with a mount-isolation flaw — tracked as CVE-2022-23648 — that allowed a malicious or compromised pod specification to escape the volume-mount boundaries Kubernetes expects containerd to enforce. In practice, an attacker who could control a pod's volume configuration (through a malicious image, a compromised CI pipeline, or a tenant with pod-creation rights in a multi-tenant cluster) could get the CRI plugin to resolve mount paths outside the container's intended filesystem view, gaining read and/or write access to arbitrary files on the underlying host. Because containerd sits underneath most managed Kubernetes offerings and self-hosted clusters alike, this wasn't a niche edge case — it touched a huge share of production container infrastructure until patched versions rolled out.

What Went Wrong

According to the GitHub Security Advisory (GHSA-crp2-qrr5-8pq7) published by the containerd maintainers, the CRI implementation did not sufficiently validate the mount specifications it handed to the OCI runtime when creating a container. Volume mounts requested through a pod spec — including combinations involving subPath and certain bind-mount configurations — could resolve to paths outside the volume the Kubernetes volume subsystem intended to expose. The container's mount namespace was supposed to constrain it to a specific directory tree; the bug let that constraint be bypassed, effectively giving the container a window into the host filesystem it should never have been able to see.

This is a mount-isolation bug, not a container-escape-via-kernel-exploit bug, which matters for how you think about blast radius: exploitation didn't require a kernel vulnerability or privileged container flags. It only required the ability to define a pod's volume configuration — something any user with namespace-scoped pod-creation permissions typically has.

Affected Versions and Components

• Component: containerd, specifically the cri plugin (containerd/containerd)
• Affected versions: containerd releases prior to 1.6.4, prior to 1.5.11, and prior to 1.4.13
• Fixed in: containerd 1.6.4, 1.5.11, and 1.4.13
• Downstream exposure: any platform bundling an unpatched containerd — including Kubernetes distributions, managed Kubernetes services, Docker Engine (which uses containerd internally on modern versions), and standalone containerd deployments used by CI runners or serverless container platforms

If your environment runs Kubernetes with containerd as the CRI runtime (the default for most current clusters, since dockershim's removal), and you haven't confirmed a containerd version at or above the fixed releases above, you should treat this as unresolved until verified.

Severity Snapshot

• CVSS: NVD scores CVE-2022-23648 in the medium range (base score in the high-5s), reflecting a local attack vector, low attack complexity, low privileges required, no user interaction, and a confidentiality impact without a corresponding integrity or availability rating in the base metric — though in real deployments the practical impact frequently extends to integrity as well, since write access to host paths can enable follow-on tampering.
• EPSS: Exploit Prediction Scoring System values for this CVE have stayed low, consistent with a vulnerability that requires an attacker to already hold pod-creation or image-supply capability rather than being remotely and anonymously exploitable — it's not a vulnerability that shows up in opportunistic internet scanning.
• CISA KEV: As of this writing, CVE-2022-23648 does not appear on CISA's Known Exploited Vulnerabilities catalog. That is not the same as "safe to ignore" — KEV listing reflects confirmed in-the-wild exploitation, and container mount-escape primitives are exactly the kind of building block that shows up in multi-stage supply chain and cluster-tenancy attacks without ever generating the telemetry needed for KEV inclusion.

The net read: this is a moderate-severity, locally-scoped vulnerability whose real danger shows up in shared, multi-tenant, or CI-heavy Kubernetes environments where "who can define a pod spec" is a broader set of people (and pipelines) than "who has cluster-admin."

Timeline

• Discovery and coordinated disclosure: The containerd maintainers identified and privately fixed the mount-handling issue as part of a coordinated patch release covering several CRI plugin bugs.
• April 2022: containerd 1.6.4, 1.5.11, and 1.4.13 were released with the fix, and the GitHub Security Advisory GHSA-crp2-qrr5-8pq7 was published alongside the corresponding CVE-2022-23648 record.
• Following weeks: Downstream distributions — managed Kubernetes services, Docker Engine, and Linux distro package maintainers — pulled in the patched containerd releases on their own update cadences, meaning the effective remediation timeline for any given cluster depended heavily on how quickly its platform vendor shipped an update.
• Ongoing: Because containerd is a foundational, widely vendored component, unpatched instances have continued to surface in SBOM and image-scanning audits well after the original fix, particularly in long-lived base images, vendored binaries, and air-gapped or slow-patch-cycle environments.

Remediation Steps

1. Identify your containerd version everywhere it runs. Check Kubernetes nodes (containerd --version or crictl info), CI runners, and any standalone container hosts. Don't rely on "what version did we install" — verify what's actually running, since base image updates and node pool rebuilds can leave stragglers.
2. Upgrade to a fixed release. Move to containerd 1.6.4+, 1.5.11+, or 1.4.13+ (or later releases in those lines). If you're on a managed Kubernetes service, confirm your node image or containerd add-on version has incorporated the fix rather than assuming the platform auto-patched it.
3. Audit and restrict pod-creation permissions. Since exploitation requires control over a pod's volume specification, tighten RBAC so that only trusted service accounts and users can create or modify pods, especially in shared/multi-tenant namespaces.
4. Apply Pod Security Standards or an admission controller. Enforce restrictions on volume types (particularly hostPath), disallow unnecessary bind mounts, and use policy engines (OPA/Gatekeeper, Kyverno, or built-in Pod Security Admission) to block pod specs that request suspicious mount configurations.
5. Re-scan images and running workloads after patching. Confirm your container and node images no longer report the vulnerable containerd version, and re-validate any CI base images or golden AMIs that bundle containerd directly.
6. Review audit logs for anomalous volume/mount activity covering the exposure window, particularly pod creations with unusual subPath or bind-mount parameters from namespaces or service accounts that don't normally need host-adjacent access.

How Safeguard Helps

Tracking down every place containerd is vendored — base images, node pools, CI runners, air-gapped clusters — is exactly the kind of sprawling dependency problem that manual audits miss and generic scanners flag without context. Safeguard's SBOM generation and ingestion pipeline builds a live inventory of containerd (and every other runtime component) across your fleet, so you know precisely which clusters and images are still exposed to CVE-2022-23648 rather than guessing from patch notes. Griffin AI then applies reachability analysis to that inventory, distinguishing nodes where the vulnerable CRI mount path is actually invokable from pod-creation permissions your teams hold versus environments where compensating RBAC or admission policy already closes the door — cutting through alert noise so security teams chase real exposure, not theoretical CVSS scores. Where remediation is straightforward, Safeguard's auto-fix PRs open the version bump and any accompanying admission-policy hardening directly against the affected manifests and base image definitions, turning a multi-team patch coordination effort into a reviewable pull request. For supply chain security teams competing on speed of remediation as much as depth of detection, that combination — inventory, reachability, and automated fix delivery — is what turns a CVE bulletin into a closed ticket.