CVE-2026-15218: maas-api · Incorrect Privilege Assignment
Affects maas-apiSource CVE Database V5
Not known to be exploited · CVSS 7.9 High.
Data as of 26 Oct 2026, 10:24 UTC
- EPSS
- 0.7% chance of exploitation in 30 days – higher than 53% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- CISA SSVC
- Exploitation
- No evidence of active exploitation and no public proof of concept
- Automatable
- Attackers cannot reliably automate steps 1–4 of the kill chain
- Technical impact
- Total control over the software or total information disclosure
CISA SSVC assessment, 2026-08-17.
CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:LExploitation evidence
Disclosed: evidence found.
CVE published 17 Aug 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 24 Oct 2026.
What to do
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| maas-api | Affected
| Fixed in– |
| maas-controller | Affected
| Fixed in– |
GitHubmaas-apipkg:github/maas-apiOther threats | Affected
| Fixed in– |
GitHubmaas-controllerpkg:github/maas-controllerOther threats | Affected
| Fixed in– |
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
Description
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.