Kubernetes kubelet symlink volume mount escape (CVE-2021-25741)

A symlink race condition in the Kubernetes kubelet, tracked as CVE-2021-25741, allowed a pod using a subPath volume mount to escape the boundaries of that volume and read, write, or create files anywhere on the host filesystem the kubelet could reach. In practice, a user who could deploy a pod with a crafted subPath mount — a permission many teams grant by default — could pivot from a seemingly ordinary workload into full node compromise, making this one of the more consequential kubelet-level bugs disclosed since the original subPath traversal issue three years earlier. This is exactly the class of kubernetes kubelet symlink vulnerability that security teams need to catch before it ships, not after.

What went wrong

Kubernetes subPath volume mounts let a pod mount a specific sub-directory or file from a volume rather than the whole volume — useful for sharing a ConfigMap, Secret, or PersistentVolume across containers without exposing the entire backing store. To make this safe, the kubelet resolves the subPath, verifies it stays within the volume, and only then performs the bind mount.

CVE-2021-25741 is a time-of-check-to-time-of-use (TOCTOU) flaw in that resolution logic. Between the moment the kubelet validates the subPath and the moment it actually mounts it, an attacker-controlled process inside the pod can swap a regular file or directory for a symlink that points outside the volume — for example, at /etc, /var/lib/kubelet, or another sensitive host path. The kubelet, having already validated the original (safe) path, follows the newly-swapped symlink and mounts the attacker's chosen host location into the container instead. From the container's perspective, it now has read/write access to arbitrary files on the node, including files owned by other pods or by the host OS itself.

This is functionally a bypass of the fix originally shipped for CVE-2017/2018-1002101 (the first kubelet subPath escape), and it underscores how narrow race-condition windows in privileged daemons tend to resurface in new forms rather than disappear for good.

Affected versions and components

• Component: kubelet (the node agent responsible for pod lifecycle and volume mounting)
• Feature: volumes using subPath or subPathExpr
• Affected versions:
  • kubelet < v1.19.15
  • kubelet v1.20.0 – v1.20.10
  • kubelet v1.21.0 – v1.21.4
  • kubelet v1.22.0 – v1.22.1
• Fixed versions: v1.19.15, v1.20.11, v1.21.5, v1.22.2 and later
• Prerequisite: the attacker needs the ability to create or modify a pod spec that uses a subPath mount — a capability common in multi-tenant clusters, CI/CD pipelines, and any environment where developers have namespace-level pod creation rights.

Managed Kubernetes offerings (EKS, GKE, AKS) that auto-patch node components generally rolled the fix out on their normal upgrade cadence, but self-managed clusters, air-gapped environments, and older LTS-style deployments were commonly still exposed well after the public advisory.

It's also worth noting what is not required for exploitation: no CVE-vulnerable application code, no misconfigured RBAC beyond ordinary pod-create rights, and no network access to the node. The bug lives entirely inside kubelet's own mount-handling logic, which is what makes it attractive to an attacker who has already landed a foothold inside any pod on the cluster — it turns "I have a container" into "I have a path to the underlying node."

CVSS, EPSS, and KEV context

The Kubernetes Security Response Committee rated CVE-2021-25741 High severity, with a CVSS v3.1 base score of 8.8 (vector approximately AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H), reflecting low attack complexity, low required privileges, and high impact to confidentiality, integrity, and availability once the host filesystem is exposed.

Exploitation does require some level of pre-existing access — namely the ability to schedule a pod with a subPath mount — which keeps its EPSS (Exploit Prediction Scoring System) probability comparatively modest relative to internet-facing, unauthenticated bugs. As of this writing, CVE-2021-25741 does not appear on CISA's Known Exploited Vulnerabilities (KEV) catalog, meaning there's no confirmed evidence of widespread in-the-wild exploitation. That said, KEV absence is not a safety signal on its own: container-escape primitives like this one are exactly the kind of building block used in multi-step attack chains inside shared or multi-tenant clusters, where the "prerequisite access" is often trivially satisfied by any developer or CI job with pod-create permissions.

Timeline

• August 2021 — The issue is identified and privately reported to the Kubernetes Security Response Committee by Google engineers Fabricio Voznika and Mark Wolters, who had previously worked on hardening the original subPath fix.
• Private fix development — Patches are developed and backported across the four maintained release branches (1.19 through 1.22) under embargo.
• September 6, 2021 — Kubernetes publishes the coordinated disclosure and patched releases (v1.19.15, v1.20.11, v1.21.5, v1.22.2), alongside advisory GHSA-fj9j-mch4-fpm5 and the public CVE-2021-25741 record.
• Following weeks — Cloud providers and distribution maintainers (EKS, GKE, AKS, OpenShift, Rancher, and others) roll out patched node images and publish their own advisories referencing the upstream fix.
• Ongoing — Clusters running unmaintained or delayed-patch kubelet versions remain exposed indefinitely, since the vulnerability lives in node-level binaries that require an explicit upgrade rather than a config change.

Remediation steps

1. Patch the kubelet on every node. Upgrade to v1.19.15, v1.20.11, v1.21.5, v1.22.2, or later. Because this is a node-agent bug, patching only the control plane is not sufficient — every kubelet in the cluster must be upgraded, including nodes managed by separate node pools, self-hosted worker fleets, or edge/on-prem clusters.
2. Inventory subPath usage before and after patching. Query running workloads for subPath and subPathExpr references (kubectl get pods -A -o json | jq against .spec.containers[].volumeMounts[].subPath is a quick start) to understand your actual exposure surface and prioritize which node pools to patch first.
3. Restrict who can create pods with subPath mounts. Apply least-privilege RBAC so that only workloads which genuinely need subPath mounting can use it, and consider Pod Security Admission or OPA/Gatekeeper policies that flag or block subPath usage from lower-trust namespaces.
4. Harden the node boundary regardless of patch status. Run kubelets with restricted filesystem permissions, avoid mounting sensitive host paths into any pod, and treat node compromise as a realistic outcome of any container-escape bug — segment sensitive workloads onto dedicated node pools.
5. Validate the fix. After upgrading, confirm the kubelet version cluster-wide with kubectl get nodes -o wide and re-run any internal detection rules or admission checks that previously flagged subPath mounts as risky, since the underlying race condition is now closed.
6. Watch for regressions. This is the second subPath-related kubelet CVE in this validation logic; treat any future kubelet CVE touching volume mount resolution as high priority for immediate triage rather than routine patch-cycle handling.

How Safeguard Helps

Safeguard's reachability analysis pinpoints exactly which of your clusters actually run workloads using subPath or subPathExpr mounts, so you can prioritize the kubelet nodes that are genuinely exploitable instead of patching blindly across every environment. Griffin AI correlates that exposure with your live Kubernetes inventory and SBOM data — generated automatically or ingested from existing CI pipelines — to surface unpatched kubelet versions the moment a CVE like this is published, rather than waiting for a scheduled scan. When a fix is available, Safeguard can open auto-fix PRs against your infrastructure-as-code and node image pipelines to bump kubelet versions and tighten subPath-related RBAC policies, cutting the time between disclosure and remediation. And because container-escape bugs like CVE-2021-25741 often chain with other supply chain weaknesses, Safeguard continuously monitors your software supply chain end to end — from build to runtime — so issues like this don't sit unpatched for months in production.