CVE-2026-89419
Description
A flaw was found in OpenStack Ironic. A missing authorization check in the node PATCH API allows an authenticated lessee member to change the maintenance state of a bare metal node, an operation that should be restricted to lessee managers and administrators. By sending a PATCH request to /v1/nodes/{ident} with a maintenance field, the request is processed under the generic node-update policy rather than the stricter set_maintenance policy, bypassing the intended role boundary. This could allow a lessee member to place nodes into maintenance (disrupting scheduling and availability) or to clear maintenance mode on nodes an operator intentionally marked as under maintenance.
Statement
This vulnerability is rated Moderate because an authenticated project member who already has general node update access can toggle maintenance through the PATCH API (PR:L under default Ironic policy) without going through the dedicated maintenance endpoints that enforce stricter roles. Practical impact is mild: the main effect is operational inconvenience, including blocking power management and workflow request actions on the node until maintenance is cleared. There is no confidentiality impact and no arbitrary code execution.
The attack path applies where OpenStack Ironic is used with Keystone and project-scoped RBAC, including Red Hat OpenStack Platform and deployments that run OpenStack on OpenShift with that authorization model. OpenShift Container Platform does not use OpenStack Keystone or project-scoped lessee RBAC in any configuration; the described privilege gap does not apply to default OpenShift bare-metal Ironic in the same way. The issue remains relevant for customers deploying OpenStack on OpenShift and for RHOSP environments that grant project members general node update access.
Mitigation
There is no practical operational or policy workaround for this issue. Upgrade to a fixed Ironic build when available. Until a fix is applied, maintenance toggled through this path can block power management and workflow request actions on affected nodes until maintenance is cleared by a user with appropriate access.
Common Vulnerability Scoring System (CVSS) Score Details
Info alert:Important note
CVSS scores for open source components depend on vendor-specific factors (e.g. version or build chain). Therefore, Red Hat's score and impact rating can be different from NVD and other vendors. Red Hat remains the authoritative CVE Naming Authority (CNA) source for its products and services (see Red Hat classifications).
The following CVSS metrics and score provided are preliminary and subject to review.
CVSS v3 Score Breakdown
| Red Hat | NVD | cve.org | |
|---|---|---|---|
| Base Score | 5.4 | N/A | 5 |
| Attack Vector | Network | N/A | Network |
| Attack Complexity | Low | N/A | High |
| Privileges Required | Low | N/A | Low |
| User Interaction | None | N/A | None |
| Scope | Unchanged | N/A | Unchanged |
| Confidentiality | None | N/A | Low |
| Integrity Impact | Low | N/A | Low |
| Availability Impact | Low | N/A | Low |
Vector
Red Hat: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L
cve.org: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L
Red Hat CVSS v3 Score Explanation
PR:L for authenticated member with baremetal:node:update; maintenance toggle via PATCH; mild impact (power management and workflow actions blocked until maintenance cleared)
Acknowledgements
Upstream acknowledges Dmitry Tantsur (Red Hat) and Tuomo Tanskanen (Ericsson Software Technology) as the original reporters.
Frequently Asked Questions
Not sure what something means? Check out our Security Glossary.
Want to get errata notifications? Sign up here.
