Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2024-25131

CVE-2024-25131: OpenShift Dedicated Privilege Escalation

CVE-2024-25131 is a privilege escalation flaw in OpenShift Dedicated MustGather CRD that allows non-privileged users to escalate to cluster administrator. This post explains its impact, affected versions, and mitigation steps.

Published:

CVE-2024-25131 Overview

CVE-2024-25131 is a privilege escalation vulnerability in the MustGather.managed.openshift.io Custom Resource Definition (CRD) used by Red Hat OpenShift Dedicated. A non-privileged user can create a MustGather object referencing a crafted file and assign a highly privileged service account to execute the job. This design flaw allows a standard developer-level user to escalate to cluster administrator and pivot into the underlying AWS environment hosting the cluster. The issue is categorized under improper input validation [CWE-20].

Critical Impact

An authenticated developer user can obtain cluster-admin privileges on OpenShift Dedicated and pivot to the AWS control plane, breaking multi-tenant isolation.

Affected Products

  • Red Hat OpenShift Dedicated
  • must-gather-operator (upstream project on GitHub)
  • Clusters exposing the MustGather.managed.openshift.io CRD

Discovery Timeline

  • 2024-12-19 - CVE-2024-25131 published to NVD
  • 2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-25131

Vulnerability Analysis

The must-gather-operator in OpenShift Dedicated processes MustGather custom resources to collect diagnostic data. The controller does not sufficiently restrict which service account a requesting user can bind to the resulting job. A low-privileged user can submit a MustGather object that instructs the operator to run the collection job under a service account with cluster-admin or equivalent permissions.

Combined with insufficient validation of the input file referenced by the object, the attacker gains code execution inside a pod running with elevated credentials. From that pod, the attacker can enumerate secrets, mint tokens, and access AWS Identity and Access Management (IAM) roles associated with the cluster's service accounts.

Root Cause

The root cause is improper input validation [CWE-20] in the MustGather controller. The controller trusts user-supplied fields, including the service account name and the file payload, without enforcing that the requester holds the permissions of the referenced account. This violates the principle of least privilege at the CRD admission layer.

Attack Vector

An authenticated user with permission to create MustGather objects submits a resource specifying a privileged service account and a crafted file. The operator reconciles the object and launches a job under the specified identity. The attacker's payload executes with the privileges of the chosen service account, yielding cluster-admin access and, through the AWS Security Token Service (STS) integration, credentials for the AWS environment.

No verified exploit code has been published. See the Red Hat CVE-2024-25131 Advisory and the fix commits in GitHub Pull Request #135 and GitHub Pull Request #138 for technical details.

Detection Methods for CVE-2024-25131

Indicators of Compromise

  • Creation of MustGather.managed.openshift.io objects by user accounts that do not normally submit diagnostic requests.
  • Jobs spawned by the must-gather-operator running under highly privileged service accounts such as cluster-admin bindings.
  • Unexpected pod executions in the openshift-must-gather-operator namespace referencing user-controlled files.
  • AWS CloudTrail events showing STS AssumeRoleWithWebIdentity calls from must-gather pods to non-diagnostic roles.

Detection Strategies

  • Audit Kubernetes API server logs for create operations on the mustgathers.managed.openshift.io resource and correlate the requesting user with the serviceAccountRef field.
  • Alert on any MustGather object whose service account resolves to a ClusterRoleBinding granting cluster-admin.
  • Compare the container image and command line of newly launched must-gather jobs against a known-good baseline.

Monitoring Recommendations

  • Forward OpenShift audit logs and AWS CloudTrail events to a centralized analytics platform for correlation across the Kubernetes and cloud control planes.
  • Continuously monitor RoleBindings and ClusterRoleBindings tied to service accounts used by operators.
  • Track privilege escalation patterns following MustGather object creation, including token requests and secret reads.

How to Mitigate CVE-2024-25131

Immediate Actions Required

  • Apply the Red Hat OpenShift Dedicated update that ships the patched must-gather-operator as described in the Red Hat CVE-2024-25131 Advisory.
  • Restrict create access on mustgathers.managed.openshift.io to trusted administrators using RBAC.
  • Review recent MustGather object history for suspicious service account references and rotate any credentials that may have been exposed.

Patch Information

Red Hat has addressed the flaw in the must-gather-operator through upstream fixes tracked in GitHub Pull Request #135 and GitHub Pull Request #138. OpenShift Dedicated customers receive the fix through the managed service update channel. Refer to Red Hat Bug Report #2258856 for the vendor tracking record.

Workarounds

  • Remove or narrow RBAC permissions that allow non-administrative users to create MustGather custom resources until the operator is patched.
  • Enforce an admission policy (for example, using OpenShift's admission plugins or a policy engine) that rejects MustGather objects specifying privileged service accounts.
  • Audit and, where possible, reduce the permissions granted to service accounts used by the must-gather-operator to align with least privilege.

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.