CVE-2025-13888: Openshift-gitops-operator: openshift gitops: namespace admin cluster takeover via privileged jobs
A flaw was found in OpenShift GitOps. Namespace admins can create ArgoCD Custom Resources (CRs) that trick the system into granting them elevated permissions in other namespaces, including privileged namespaces. An authenticated attacker can then use these elevated permissions to create privileged workloads that run on master nodes, effectively giving them root access to the entire cluster.
Other sources
Security issue with OpenShift GitOps that basically allows namespace admins to overtake the whole cluster. If you can create ArgoCD CRs, you basically can overtake the whole cluster. This permission is currently granted to all namespace admins, created with a RoleBinding that binds the ClusterRole admin.
This is how you can achieve it:
When you create a ArgoCD CR in your own namespace (where you are namespace admin) you can specify sourceNamespaces under spec. You can provide whatever namespace you want here (even tho the operator checks wheter the target namespace already has the label). For example, I could specify the namespace default here. Due to the check of the operator, this is only possible for namespaces where this label is not set yet.
When I do create the ArgoCD CR the operator will annotate the specified sourceNamespaces with the label: argocd.argoproj.io/managed-by-cluster-argocd: test-1
In this case test-1 is the name of my namespace where I am namespace admin. For this example I used the default namespace as my sourceNamespace.
Additionally the Operator will create a RoleBinding and a Role within the namespace (in this example the default namespace). The Role allows the managing of ArgoCD Resources but also creation and updating of CronJobs and Jobs. The Rolebinding binds the Role to the ServiceAccounts that are used by my ArgoCD (argocd-server and argocd-application-controller) instance where I have access to.
So now I have access to two ServiceAccounts and their token which are able to create Jobs / Cronjobs in my defined sourceNamespace.
In my example I used the default namespace. The default namespace has the privileged SCC so I am able to run privileged Jobs.
Now I can extract the token of the SericeAccounts that are used by my ArgoCD instance and use it to create a privileged Job in the default namespace. The job can even run on Master nodes so basically, I have root access to the master nodes and can fully overtake the cluster without a problem.
This seems to be a security issue from my point of view because all it needs is a namespace admin to overtake the whole cluster.
— Red Hat
Affected Software
Event History
Frequently Asked Questions
What is the severity of CVE-2025-13888?
CVE-2025-13888 has been classified with a severity rating that indicates a significant risk due to the potential for unauthorized privilege escalation.
How do I fix CVE-2025-13888?
To remediate CVE-2025-13888, update to the latest version of Red Hat OpenShift GitOps that addresses this vulnerability.
Who is affected by CVE-2025-13888?
CVE-2025-13888 affects users of Red Hat OpenShift GitOps who have the ability to manage ArgoCD Custom Resources.
What are the potential consequences of CVE-2025-13888?
The potential consequences of CVE-2025-13888 include unauthorized access to privileged namespaces and elevated permissions within the cluster.
Is there a workaround for CVE-2025-13888?
Currently, there are no documented workarounds for CVE-2025-13888 other than applying the recommended updates.