Skip to main content

OpenShift GitOps CVE-2025-13888

CRITICAL
Incorrect Privilege Assignment (CWE-266)
2025-12-15 secalert@redhat.com
9.1
CVSS 3.1 · Vendor: redhat
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Obtain namespace-admin in a tenant namespace
  2. Delivery
    Create crafted ArgoCD Custom Resource
  3. Exploit
    Operator grants elevated cross-namespace permissions
  4. Execution
    Deploy privileged workload on master node
  5. Impact
    Gain root over entire cluster

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V8 - Authorization Privilege assignment review
Exploitation Conditions

Requires an authenticated attacker who already holds namespace-admin privileges in a namespace on a cluster running Red Hat OpenShift GitOps (Argo CD operator) prior to v1.16.2. The attacker must be able to create ArgoCD Custom Resources that the operator reconciles; the flaw lets those CRs coerce the operator into granting permissions in other, including privileged, namespaces (the fix specifically restricts application of the openshift.io/cluster-monitoring namespace label to openshift- prefixed namespaces). Limiting factors: PR:H means single-tenant clusters or environments where namespace admins are already fully trusted see little added exposure; there is no unauthenticated or user-interaction path, and the primary risk is in multi-tenant/shared OpenShift clusters with semi-trusted tenants.

Impact

Signals conflict between a high paper severity and moderate real-world urgency. The vendor CVSS 3.1 base score is 9.1 (Critical) with vector AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H, which I concur with: exploitation crosses a trust boundary (S:C) from a single namespace to the entire cluster, yielding full CIA impact (cluster root). However, PR:H is the critical tempering factor - the attacker must already hold namespace-admin privileges, so this is a privilege-escalation/lateral-movement primitive for an authenticated tenant, not an unauthenticated internet-facing RCE. EPSS is 0.69% (51st percentile), consistent with no public exploit and no active exploitation: there is no CISA KEV listing and no POC in the provided sources. No SSVC decision data was provided. The input Tag 'Information Disclosure' materially understates the flaw - this is full cluster takeover (privilege escalation to root), not mere disclosure. Net: a genuine priority for multi-tenant OpenShift clusters where namespace admins are semi-trusted, but the PR:H barrier and absence of exploitation evidence place it below internet-facing critical bugs.

Exploit ScenarioDerived

A user holding namespace-admin rights on a single tenant namespace in a shared OpenShift cluster creates an ArgoCD Custom Resource crafted so the GitOps operator reconciles it with elevated, cross-namespace permissions (e.g., mislabeling privileged namespaces such as openshift- monitoring targets). Using those elevated permissions, the attacker deploys a privileged workload scheduled onto master/control-plane nodes, obtaining root over the whole cluster. No public exploit code is identified at time of analysis; exploitation requires an existing authenticated namespace-admin foothold.

Act Now Prioritize within 24-48h. Why: CRITICAL severity.
Patch available 0.7% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Sep 30, 2026

Namespace administrators on OpenShift clusters running the Red Hat OpenShift GitOps (Argo CD) operator prior to v1.16.2 can craft ArgoCD Custom Resources that coerce the operator into assigning permissions in other namespaces, including privileged ones. According to the assessed vector (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H, 9.1), an authenticated attacker with namespace-admin rights can escalate from a single tenant namespace to cluster-wide root by creating privileged workloads scheduled onto master nodes; the scope change reflects the cross-namespace breakout. Exploitation requires prior namespace-admin privilege (PR:H), so multi-tenant shared clusters with semi-trusted tenants carry the real risk, while single-tenant environments where namespace admins are already trusted see limited added exposure; no public exploit identified at time of analysis and the EPSS score is only 0.69% (51st percentile), indicating low observed exploitation activity despite the high paper severity.

RemediationAI

Apply the vendor-released patch by upgrading the OpenShift GitOps operator to v1.16.2 or later, available through Red Hat errata RHSA-2025:23203, RHSA-2025:23206, RHSA-2025:23207, and RHSA-2026:1017 (see https://access.redhat.com/security/cve/CVE-2025-13888 and the upstream fix at https://github.com/redhat-developer/gitops-operator/pull/897 and release https://github.com/redhat-developer/gitops-operator/releases/tag/v1.16.2). If immediate upgrade is not possible, the most effective compensating control is to remove the ability for untrusted namespace admins to create or modify ArgoCD Custom Resources in the argoproj.io API group, typically by tightening RBAC/ClusterRole bindings so that only trusted operators and cluster administrators hold write access to those CRs; the trade-off is that self-service GitOps provisioning by tenant teams stops working and must be replaced by a request-and-approve workflow or a centrally managed ArgoCD instance. Additionally, restrict who can set or influence the 'openshift.io/cluster-monitoring' label on namespaces (namespace-admin label write permissions) and audit for existing namespaces outside the 'openshift-' prefix that already carry that label, since the patched code confines it to OpenShift system namespaces; removing the label from non-system namespaces may disable intended monitoring for those tenant namespaces, so those teams should instead use 'openshift.io/user-monitoring'. Finally, monitor audit logs for namespace-admin principals creating ArgoCD CRs and for subsequent privileged workload creation on master/control-plane nodes, as this chain is the observable exploitation path (note: no public exploit code identified at time of analysis, and EPSS remains low at 0.69%).

Affected Packages

go github.com/redhat-developer/gitops-operator fix: 1.16.2

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in go

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

The flaw is rooted in CWE-266 (Incorrect Privilege Assignment) within the Red Hat OpenShift GitOps operator (redhat-developer/gitops-operator), which reconciles ArgoCD Custom Resources on behalf of users. The upstream fix commit bc6ac3e03d7c8b3db5d8f1770c868396a4c2dcef in controllers/argocd_metrics_controller.go shows the operator previously applied the cluster-monitoring label 'openshift.io/cluster-monitoring' to namespaces referenced by user-supplied ArgoCD CRs without distinguishing system namespaces. Because that label is a hook the monitoring stack and related controllers use to enable privileged behavior, a namespace admin able to create ArgoCD CRs could cause the operator - running with elevated cluster privileges - to apply the label and associated configuration to arbitrary namespaces, effectively laundering the attacker's permissions into higher-trust namespaces and permitting privileged workloads on control-plane (master) nodes. The patch splits behavior by namespace prefix: namespaces beginning with 'openshift-' now use 'openshift.io/cluster-monitoring', while all others are constrained to the user-defined 'openshift.io/user-monitoring' label. The affected technology is Kubernetes Operator/Controller reconciliation combined with Argo CD declarative GitOps state, where the operator's cluster-scoped service account becomes the privilege amplifier.

Know when Red Hat gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (redhat) PRIMARY 9.1 CRITICAL
AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
vuln.today AI 9.1 CRITICAL

Namespace-admin foothold required so PR:H; attack via Kubernetes API is network AV:N/AC:L; escalation crosses namespace to cluster (S:C) giving full cluster-root CIA impact.

3.1 AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
4.0 AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
SUSE CRITICAL
Red Hat 9.1 HIGH

Primary rating from Vendor (redhat).

CVSS VectorVendor: redhat

Attack Vector
Network
Attack Complexity
Low
Privileges Required
High
User Interaction
None
Scope
Changed
Confidentiality
High
Integrity
High
Availability
High

DescriptionCVE.org

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.

Executive ViewAI

Why It Matters

Red Hat OpenShift GitOps (Argo CD) operator prior to v1.16.2 contains a critical privilege-escalation flaw that allows an authenticated tenant with namespace-admin rights to break out of its namespace and gain cluster-wide root, potentially compromising all workloads and data on shared OpenShift clusters. This risk is most acute for multi-tenant clusters where semi-trusted tenants are granted namespace-admin, because it defeats tenant isolation and can lead to full cluster takeover; single-tenant environments with fully trusted namespace admins face lower incremental risk. No public exploit identified at time of analysis, and no vendor-released patch is available, so leadership should prioritize interim hardening and monitoring.

Business Impact: Severe
Compensating Controls

Restrict namespace-admin and ArgoCD Custom Resource creation to fully trusted users; enforce least-privilege RBAC and Pod Security Admission/SCCs to prevent privileged workloads, especially on master nodes; enable audit logging and alerting for cross-namespace role bindings and privileged pod creation; segregate high-risk tenants onto separate clusters until a vendor patch is available.

Threat Intelligence Overview

EPSS Score
0.7%
Top 49% exploitable
Prevalence
Medium
Red Hat OpenShift GitOps add-on operator, common in OpenShift shops but not universal
Data Quality
4 sources
Confidence: Medium

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity CRITICAL
CISA KEV No
Public POC No
EPSS 0.7%
Patch available Yes
Active threat No
Deciding rule
CRITICAL severity
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation· derived
None
System Exposure· derived
Open
Automatable· derived
No
Human Impact
Very High

Priority Score

47
Low Medium High Critical
KEV: 0
EPSS: +1
CVSS: +46
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0
CVE-2026-72526 CRITICAL
9.9 Aug 12

Cross-cluster remote code execution in Red Hat Advanced Cluster Management for Kubernetes 2 (multicloud-integrations / A

CVE-2026-70398 CRITICAL
9.6 Aug 12

Cross-tenant bearer-token disclosure in Red Hat Advanced Cluster Management for Kubernetes 2 (RHACM) lets an authenticat

CVE-2026-18963 CRITICAL POC
9.1 Aug 18

Account takeover in Red Hat Build of Keycloak allows an unauthenticated attacker to abuse the reset-credentials flow in

CVE-2026-18663 MEDIUM
5.9 Aug 12

Heap corruption via double-free in 389-ds-base's LDAP control parsing allows an unauthenticated remote attacker to crash

CVE-2026-4631 CRITICAL POC
9.8 Apr 07

Remote code execution in Cockpit's web interface allows unauthenticated attackers to execute arbitrary commands on the h

CVE-2026-4480 CRITICAL POC
9.0 May 26

Remote code execution in Samba's printing subsystem allows remote attackers to inject arbitrary shell commands via craft

CVE-2026-92574 HIGH POC
8.8 Sep 21

Elevated-privilege container restoration in CRI-O 1.34 and later, including downstream Red Hat OpenShift Container Platf

CVE-2026-73122 HIGH
7.7 Aug 12

Unauthorized cross-tenant Secret and ConfigMap access in the multicloud-operators-channel component of Red Hat Advanced

CVE-2026-66878 HIGH
7.7 Aug 12

Secret exfiltration across Kubernetes namespace boundaries in the multicloud-operators-subscription component of Red Hat

CVE-2026-101258 HIGH POC
7.8 Oct 06

Ghostscript can execute arbitrary shell commands with the privileges of its process when it renders a crafted PostScript

CVE-2025-14874 HIGH POC
7.5 Dec 18

Unbounded recursion in Nodemailer's address parser (npm package versions 3.0.0 through 7.0.10) allows a single crafted e

CVE-2026-23536 HIGH POC
7.5 Mar 20

The Feast Feature Server contains a path traversal vulnerability in its `/read-document` endpoint that allows unauthenti

Vendor StatusVendor

SUSE

Severity: Critical
Product Status
SUSE Linux Enterprise Server 16.1 Affected
SUSE Linux Enterprise Server for SAP applications 16.1 Affected
SUSE Linux Enterprise Server 16.2 Affected

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy