Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessExploit separate RCE in maas pod OR gain namespace pod-create rights
-
DeliveryDeploy malicious pod or execute within compromised pod
-
ExploitRead ServiceAccount token from pod filesystem
-
ExecutionAuthenticate to Kubernetes API as maas ServiceAccount
-
PersistCreate ClusterRoleBinding granting cluster-admin to attacker identity
-
ImpactAccess all secrets and workloads across cluster
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V8 - Authorization Privilege assignment review
|
| Exploitation Conditions | Exploitation requires one of two specific preconditions: (1) a separate exploitable RCE vulnerability present in the maas-api or maas-controller pods that grants code execution within those pods, thereby providing access to the ServiceAccount token mounted on the pod filesystem; or (2) pre-existing Kubernetes RBAC privileges permitting pod creation within the same namespace as the maas-api or maas-controller components, enabling deployment of a malicious pod that can read the ServiceAccount token. Neither path is available to an unauthenticated or low-privilege external attacker - the CVSS PR:H metric reflects that a significant prior foothold is required. What limits exploitation further is AC:H: the attacker must be positioned within the specific OpenShift AI namespace and must successfully obtain the ServiceAccount token before cluster-wide escalation is possible. Default OpenShift RBAC should prevent arbitrary namespace-level pod creation by unprivileged users. |
| Impact | The CVSS 7.9 score is driven primarily by the Scope:Changed metric and the high confidentiality and integrity impacts, reflecting that a successful exploit crosses the namespace boundary to affect the entire cluster. However, AC:H and PR:H substantially constrain exploitability: the attacker must first achieve either code execution within a maas-api or maas-controller pod (itself a separate vulnerability chain) or possess pre-existing Kubernetes privileges sufficient to create pods in the target namespace - neither of which is trivial. No EPSS score was provided in the available data, preventing quantitative exploitation probability comparison, and the CVE is not listed in the CISA KEV catalog, indicating no confirmed active exploitation at time of analysis. From an SSVC perspective, exploitation is not currently automatable (requires chained access), but the technical impact is total if exploitation succeeds. The practical priority level for organizations running OpenShift AI is elevated because the blast radius - cluster-admin equivalent across all namespaces - is severe; even a smaller operator running OpenShift AI for internal data science workloads should treat this as a high-priority remediation item rather than a theoretical risk, particularly if those environments host sensitive model artifacts or training data secrets. |
| Exploit ScenarioDerived | An attacker who has exploited a separate RCE vulnerability in a maas-api or maas-controller pod reads the ServiceAccount token from /var/run/secrets/kubernetes.io/serviceaccount/token within the compromised container. Using this token against the Kubernetes API server, the attacker issues a kubectl create clusterrolebinding command binding cluster-admin to an attacker-controlled ServiceAccount or user identity, achieving unrestricted cluster control. No public POC has been identified at time of analysis. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Aug 17, 2026
Excessive RBAC permissions on the maas-api and maas-controller ServiceAccounts in Red Hat OpenShift AI enable privilege escalation to full cluster administrator. An attacker who compromises either ServiceAccount identity - by exploiting a separate RCE vulnerability within those pods or by creating a malicious pod in the same Kubernetes namespace - can create new ClusterRoleBindings to assume cluster-admin rights or read all secrets across the cluster. No public exploit has been identified at time of analysis, and the CVSS vector confirms high privileges are required as a prerequisite, limiting the realistic threat actor pool to those with existing cluster foothold.
RemediationAI
Apply the vendor-released patch per the Red Hat security advisory at https://access.redhat.com/security/cve/CVE-2026-15218; an exact fixed version is not independently confirmed from the available data, so consult the advisory directly. As compensating controls prior to patching: audit and restrict the ClusterRoleBindings associated with the maas-api and maas-controller ServiceAccounts to least-privilege namespace-scoped roles, removing any cluster-wide secret-list or ClusterRoleBinding-create permissions not operationally required. Restrict pod creation in the affected namespaces to only trusted, operator-controlled principals using RBAC or an admission controller such as Kyverno or OPA Gatekeeper. Monitor for unexpected ClusterRoleBinding creation events via audit logs. Note that tightening ServiceAccount permissions may break functionality if the maas components legitimately depend on any of the excess rights - validate in a non-production environment first.
Affected ProductsAI
The affected components are the maas-api and maas-controller ServiceAccounts within Red Hat OpenShift AI. Specific affected version ranges are not independently confirmed from the available reference data; the Red Hat CVE page at https://access.redhat.com/security/cve/CVE-2026-15218 and the associated Bugzilla entry at https://bugzilla.redhat.com/show_bug.cgi?id=2498426 should be consulted for authoritative version scope. No CPE strings were provided in the intelligence data.
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The vulnerability is rooted in CWE-266 (Incorrect Privilege Assignment), specifically the over-provisioning of Kubernetes ClusterRole bindings on two ServiceAccounts within Red Hat OpenShift AI (formerly RHODS - Red Hat OpenShift Data Science), an enterprise ML/AI platform built on OpenShift Container Platform. In Kubernetes, ServiceAccounts are pod-level API identities whose tokens are mounted into pod filesystems at runtime. When a ServiceAccount is bound to a ClusterRole with permissions such as creating ClusterRoleBindings or listing secrets cluster-wide, any principal that obtains the ServiceAccount token - whether via pod-local file access, environment variable exposure, or a token projection attack - inherits those cluster-wide rights. The maas-api and maas-controller components are internal OpenShift AI controllers; their ServiceAccounts require only scoped permissions to function, making the cluster-wide grants a configuration over-privilege rather than a design necessity.
Know when the next one hits your stack
- 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
AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:L
High privileges required to obtain ServiceAccount token; attack complexity high due to chained access prerequisite; scope changes to cluster-wide on success.
Primary rating from Vendor (redhat).
CVSS VectorVendor: redhat
DescriptionCVE.org
A flaw was found in the maas-api and maas-controller ServiceAccounts within Red Hat OpenShift AI. These ServiceAccounts are granted cluster-wide permissions that exceed their operational requirements. An attacker who compromises the identity of these ServiceAccounts, either through a remote code execution vulnerability or by creating a malicious pod in the same namespace, could exploit these excessive permissions. This could lead to full cluster administrator privileges through the creation of new ClusterRoleBindings or the disclosure of sensitive information by accessing all secrets across the cluster.
Executive ViewAI
Red Hat OpenShift AI deployments are vulnerable to complete infrastructure compromise through misconfigured access controls that enable attackers with cluster access to escalate to full administrative privileges and exfiltrate all organizational credentials. This vulnerability exposes every application and dataset running on affected platforms, creating enterprise-wide infrastructure and data breach risk. Organizations must remediate immediately as a critical infrastructure security priority.
No vendor-released patch identified at time of analysis. Implement immediate compensating controls: (1) Apply restrictive RBAC policies limiting maas-api and maas-controller ServiceAccounts to only required permissions, removing cluster-admin access; (2) Enforce NetworkPolicies to isolate maas namespace traffic; (3) Implement Pod Security Standards to prevent privileged pod execution; (4) Enable and monitor Kubernetes audit logs for ClusterRoleBinding and secret access events; (5) Implement pod security policies (PSP) or Kyverno policies to restrict container capabilities; (6) Rotate all cluster secrets and implement secret rotation schedules; (7) Monitor for indicators of compromise including unexpected ServiceAccount token usage.
Threat Intelligence Overview
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.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Remote Code Execution represents the critical moment when an attacker successfully runs arbitrary code on a target system without physical access.
EUVD-2026-60199
GHSA-xpxj-568j-277q
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB