A Persistent Security Hole in Kubernetes Finally Addressed

The Kubernetes project has disclosed a medium-severity vulnerability (CVE-2025-1767) that affects all Kubernetes versions through the long-deprecated gitRepo volume driver. Despite being deprecated for over six years, the driver remained functional and exploitable, allowing users with pod creation permissions to achieve remote code execution on the underlying node.

The Vulnerability¶

At the center of the issue is the gitRepo volume plugin, a mechanism that allows pods to automatically clone and mount a Git repository via kubelet. While once a convenient feature, it has long been considered dangerous. In 2018, a Git-specific flaw (CVE-2018-11235) enabled attackers to embed malicious submodules, which were then executed as root via the gitRepo driver. Despite warnings and documentation updates, the plugin was never removed.

Fast forward to 2024: security researcher Imre Rad demonstrated a new, Kubernetes-specific attack using the same volume plugin. By crafting a repository that abuses the plugin’s optional directory parameter, an attacker can trick the kubelet into executing a malicious Git hook as root on the host node.

“The impact is code execution in the host’s security context... a sandbox escape.” — Imre Rad

The attack abuses how kubelet handles clone directories. If an attacker specifies a target directory like something/.git, the Git CLI treats this as a bare repo and executes post-checkout hooks placed there, all within the root context of the node.

Who is Affected?¶

Any cluster still using the gitRepo volume type is vulnerable. Specifically:

• Affected component: kubelet
• Affected versions: All
• Required privileges: create pod
• Scope: Intra-node; attacker must land on the same node as the target

The CVSS score is 6.5 (Medium), but the impact is significant due to root access on the host.

Detection¶

To identify pods using the gitRepo volume type:

If such use is found, examine cloned repositories and check for .git/hooks directories containing suspicious scripts.

Mitigation¶

Since upstream has officially deprecated the gitRepo plugin and will not issue a patch, mitigation must be enforced at the user or policy level:

• Use initContainers instead:
  Clone repos via an initContainer into a shared emptyDir and mount it in the main container.
• Enforce policies:
  Block gitRepo usage with admission policies:
  

• Use alternative controllers:
  Tools like acjs can convert gitRepo volumes to initContainer-based logic automatically.
• Upgrade and disable the feature:
  In Kubernetes v1.33, the gitRepo plugin will be disabled by default as part of KEP-5040. Clusters that still need it must explicitly re-enable it via:
  

However, this is discouraged.

Why Wasn’t It Removed Earlier?¶

Despite being deprecated for years, removing gitRepo outright was blocked by Kubernetes’ strong backward compatibility guarantees. However, the community has now acknowledged that its continued presence poses too high a risk, especially as it offers root-level access on shared infrastructure.

The driver will be disabled by default starting Kubernetes 1.33, set for release in August 2025.

Final Thoughts¶

This vulnerability highlights a broader challenge in Kubernetes: legacy features with dangerous side effects. The security community has long recommended moving away from gitRepo, and this latest CVE underscores the urgency. Kubernetes admins must audit their workloads, block usage of the plugin, and prepare for its permanent removal.

If your clusters rely on gitRepo, now is the time to refactor. Exploitation is trivial and the consequences are severe. There will be no upstream fix, only removal.