Bug 2418361 (CVE-2025-13888)

Summary:	CVE-2025-13888 openshift-gitops-operator: OpenShift GitOps: Namespace Admin Cluster Takeover via Privileged Jobs
Product:	[Other] Security Response	Reporter:	OSIDB Bzimport <bzimport>
Component:	vulnerability	Assignee:	Product Security DevOps Team <prodsec-dev>
Status:	NEW ---	QA Contact:
Severity:	high	Docs Contact:
Priority:	high
Version:	unspecified	CC:	anjoseph, jprabhak, security-response-team, wtam
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:	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.	Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Deadline:	2025-12-15

Description OSIDB Bzimport 2025-12-02 15:17:49 UTC

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.