Vulnerability feed
CVE and vendor PSIRT advisories from 13 sources, last 30 days. Updated hourly, last run
| Expand | Severity |
Score |
Advisory |
Title |
Source |
Flags |
Published |
|---|---|---|---|---|---|---|---|
| Medium | 5.4 | CVE-2026-90458 |
OpenStack Ironic before 39.0.1 allows DELETE and GET via vendor_passthru, e.g., to delete accounts from the BMC's Redfish service.
OpenStack, RedfishOpenStack Ironic
|
NVD | |||
|
CVE-2026-90458OpenStack Ironic before 39.0.1 allows DELETE and GET via vendor_passthru, e.g., to delete accounts from the BMC's Redfish service.
Executive summaryOpenStack Ironic, a bare metal server management service, contains a flaw that lets an authenticated user with vendor passthrough access send delete and read requests to arbitrary endpoints on a server's management controller (BMC) using the service's admin identity. The advisory does not state a numeric severity score, but the vendor tracker marks the related security advisory as Critical. The fix is an update to version 39.0.1 or a patched stable branch, and the advisory's fix validates subscription IDs. Technical summaryThe vulnerability is a path injection (path traversal) flaw in the Redfish vendor passthrough code, where an operator-supplied subscription ID is concatenated into a Redfish resource path without escaping. An authenticated caller with the baremetal:node:vendor_passthru permission can trigger arbitrary HTTP DELETE and GET requests on the BMC's Redfish root under the conductor's cached BMC-admin session. The advisory says vendor passthru requires SYSTEM_ADMIN, and the reviewer notes this is less risky on multi-tenant deployments. The advisory states the affected version as before 39.0.1, and the fix commits validate BMC subscription IDs on the affected stable and bugfix branches. The advisory does not state a CVSS score, a workaround, or exploitation in the wild, and it does not give detection guidance beyond the description of the impact. Summaries are generated by AI from the linked advisory text. Confirm versions and fixes at the source. Summarized from bugs.launchpad.net/ironic/+bug/2166507 Impact if exploitedConfidentialityLow IntegrityLow AvailabilityNone
How it is exploited
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N Affects
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||
| Medium | 5.0 | CVE-2026-89419 |
OpenStack Ironic before 39.0.1 sometimes allows a user to change the maintenance setting on a node via PATCH to /v1/nodes/{ident} - in other words, not using the specific...
OpenStackOpenStack Ironic
|
NVD | |||
|
CVE-2026-89419OpenStack Ironic before 39.0.1 sometimes allows a user to change the maintenance setting on a node via PATCH to /v1/nodes/{ident} - in other words, not using the specific...
Executive summaryOpenStack Ironic, a bare metal server management component, before version 39.0.1 lets a lessee project member change a node's maintenance setting through a PATCH request, bypassing the policy meant to restrict that action to lessee admins. The advisory does not state a severity rating or score, but the Launchpad bug was marked Critical by the maintainers. The vendor recommends applying the fixed Ironic releases, which the advisory lists as fix commits for master, stable/2026.2, stable/2026.1, stable/2025.2, stable/2025.1, unmaintained/2024.1, bugfix/38.0 and bugfix/37.0. Technical summaryThe flaw is a policy bypass (improper authorization) in the Ironic API PATCH handler for /v1/nodes/{ident}, where the per-field policy table omits the /maintenance and /maintenance_reason paths, so the generic baremetal:node:update rule is applied instead of the stricter set_maintenance and clear_maintenance rules. The attacker must be an authenticated Keystone user with the member role who is the project lessee of the node. The advisory names fixed versions only as fix branches (master, stable/2026.2, stable/2026.1, stable/2025.2, stable/2025.1, unmaintained/2024.1, bugfix/38.0, bugfix/37.0) and does not state specific fixed version numbers, though the title references 'before 39.0.1'. The advisory describes a regression test that can be added to the RBAC YAML tests, but the advisory does not state a workaround or any detection guidance. Exploitation in the wild is not stated. The CVSS score is not stated. Summaries are generated by AI from the linked advisory text. Confirm versions and fixes at the source. Summarized from bugs.launchpad.net/ironic/+bug/2166510 Impact if exploitedConfidentialityLow IntegrityLow AvailabilityLow
How it is exploited
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L Affects
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||
| Medium | 4.3 | CVE-2026-115638 |
OpenStack Ironic through 39.0.1 allows a denial of service via a configdrive that results in a very large amount of uncompressed data, aka a gzip bomb.
OpenStackOpenStack Ironic
|
NVD | |||
|
CVE-2026-115638OpenStack Ironic through 39.0.1 allows a denial of service via a configdrive that results in a very large amount of uncompressed data, aka a gzip bomb.
Executive summaryOpenStack Ironic, the bare-metal server provisioning service, is affected by a denial of service flaw. Any tenant allowed to deploy nodes can submit a specially crafted compressed configuration drive that expands to a very large size and can exhaust memory or disk on the conductor. The advisory does not state a severity score, and the fix has been merged to the master branch with backport changes proposed for several stable branches. Technical summaryThe flaw is a gzip bomb, a decompression denial of service, in the handling of base64-encoded gzip configdrive images supplied to Ironic node provision_state APIs by an authorized tenant. The conductor decompresses the image without a size limit, so a very small input can cause out-of-memory or out-of-disk conditions. The affected functions named are check_and_patch_configdrive in ironic/conductor/configdrive_utils.py and decode_and_extract_config_drive_iso in ironic/common/kickstart_utils.py. The fix, committed to master, chunks the decompression and enforces a 64MiB limit. Affected version ranges beyond the 'through 39.0.1' description are not clearly stated, and the fixed release version numbers are not stated. Backport reviews exist for stable/2026.2, stable/2026.1, stable/2025.2, bugfix/38.0, bugfix/37.0 and stable/2025.1, but the advisory does not say which releases contain the fix. No workaround beyond restricting tenant access is stated, and no detection guidance or exploitation in the wild is stated. Summaries are generated by AI from the linked advisory text. Confirm versions and fixes at the source. Summarized from bugs.launchpad.net/ironic/+bug/2171814 Impact if exploitedConfidentialityNone IntegrityNone AvailabilityLow
How it is exploited
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L Affects
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||
| Medium | 4.3 | CVE-2026-93856 |
In OpenStack Cinder through 29.0.0, cross-project information disclosure can occur in the Messages API
OpenStackOpenStack Cinder
|
NVD | |||
|
CVE-2026-93856In OpenStack Cinder through 29.0.0, cross-project information disclosure can occur in the Messages API
Executive summaryA flaw in OpenStack Cinder's Messages API allowed a non-admin user with only the project-scoped reader or member role to see user messages belonging to other projects, including resource UUIDs. The advisory rates the issue Medium in its original report, and the advisory does not state a final severity score. The vendor's fix is a code change that limits message queries to the caller's own project, and fixed releases are listed for several stable branches. Technical summaryThis is a cross-project information disclosure caused by a missing project filter in the Cinder message list path (GET /v3/messages), where the default for project_only in _messages_get_query was False. The attack requires only a valid project-scoped member or reader account on any project, with no admin rights or user interaction. The advisory lists affected versions as >=9.0.0 <26.3.1, ==27.0.0, ==28.0.0 and ==29.0.0, and the fix is in master and the stable/2026.2, stable/2026.1, stable/2025.2 and stable/2025.1 branches, plus unmaintained/2024.1, with the default changed to project_only=True. The advisory does not state a specific fixed version number for each branch, nor any workaround. No detection guidance or evidence of exploitation in the wild is stated. Summaries are generated by AI from the linked advisory text. Confirm versions and fixes at the source. Summarized from bugs.launchpad.net/cinder/+bug/2160671 Impact if exploitedConfidentialityLow IntegrityNone AvailabilityNone
How it is exploited
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N Affects
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||
| Critical | 9.9 | CVE-2026-71195 |
In OpenStack Manila before 23.0.1, multiple Manila API operations on public shares do not verify that the caller owns the share
OpenStackOpenStack Manila, OpenStack Shared File Systems Service (Manila)
|
NVD | |||
|
CVE-2026-71195In OpenStack Manila before 23.0.1, multiple Manila API operations on public shares do not verify that the caller owns the share
Executive summaryA flaw in OpenStack Manila lets a user in one project modify access rules and export location metadata on a public share owned by a different project. The advisory describes this as a serious cross-tenant authorization problem, and the vendor's reviewers agreed it should be fixed with patches to master and stable branches. The advisory text provided does not state a CVSS score or a fixed version number. Technical summaryThe root cause is missing ownership checks on public shares: the API authorizes writes before loading the target share, substitutes the caller's own project as the policy target, and the write path does not re-authorize against the share's real project. An authenticated project member can add, update, or deny access rules on another project's public share and can write or delete export location metadata on it. The advisory's reproduction used Keystone authentication with default Manila policy in a DevStack lab, and it lists affected upstream tags 20.0.0, 21.0.0, and 22.0.0 with the master branch also affected. The advisory does not state a fixed version number, and it gives no workaround. Detection guidance is not stated, apart from the reproduction requests and the access rule and metadata endpoints described in the report. Summaries are generated by AI from the linked advisory text. Confirm versions and fixes at the source. Summarized from launchpad.net/bugs/2161412 Impact if exploitedConfidentialityHigh IntegrityHigh AvailabilityHigh
How it is exploited
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H AffectsOpenStackOpenStack ManilaOpenStack Shared File Systems Service (Manila)
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||
| High | 7.2 | CVE-2026-97147 |
In OpenStack Mistral through 23.0.0, several of the v2 API write paths resolve the target object with a query that can return another project's resource, then write to it
OpenStackOpenStack Mistral
|
NVD | |||
|
CVE-2026-97147In OpenStack Mistral through 23.0.0, several of the v2 API write paths resolve the target object with a query that can return another project's resource, then write to it
From the advisoryIn OpenStack Mistral through 23.0.0, several of the v2 API write paths resolve the target object with a query that can return another project's resource, then write to it. An authenticated project member can use this to rewrite and un-publish another project's public action definitions and environments. A project administrator can create a workbook whose embedded ad-hoc action or workflow name collides with a resource of another project, which moves that resource into the caller's project and causes the original owner's subsequent updates of it to fail with server errors. Only deployments exposing the Mistral API are affected. Impact if exploitedConfidentialityLow IntegrityHigh AvailabilityLow
How it is exploited
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X Affects
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||
| Medium | 6.0 | CVE-2026-93861 |
In OpenStack Mistral through 23.0.0, the workflow membership API lets a project that has accepted a share of another project's private workflow create a further membership...
OpenStackOpenStack Mistral
|
NVD | |||
|
CVE-2026-93861In OpenStack Mistral through 23.0.0, the workflow membership API lets a project that has accepted a share of another project's private workflow create a further membership...
From the advisoryIn OpenStack Mistral through 23.0.0, the workflow membership API lets a project that has accepted a share of another project's private workflow create a further membership naming a third project. The new membership row is created with its project_id defaulted to the accepting project rather than the original workflow owner, and thus the owner can neither see nor delete it. The third project can accept this membership (that it had not actually been granted by the owner), and then read and execute the owner's private workflow; only the accepting (not the owning) project can later revoke that access. Impact if exploitedConfidentialityHigh IntegrityNone AvailabilityNone
How it is exploited
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X Affects
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||
| High | 7.1 | CVE-2026-93860 |
In OpenStack Mistral through 23.0.0, the /v2/maintenance API controller clears the request context and calls the maintenance service directly without any policy enforcement
OpenStackOpenStack Mistral
|
NVD | |||
|
CVE-2026-93860In OpenStack Mistral through 23.0.0, the /v2/maintenance API controller clears the request context and calls the maintenance service directly without any policy enforcement
From the advisoryIn OpenStack Mistral through 23.0.0, the /v2/maintenance API controller clears the request context and calls the maintenance service directly without any policy enforcement. Any holder of a valid Mistral token, regardless of assigned role, can read and change the service's cluster-wide maintenance state. Setting the state to PAUSED stops processing of new workflow and execution objects across all tenant projects until an operator restores it. Impact if exploitedConfidentialityNone IntegrityNone AvailabilityHigh
How it is exploited
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X Affects
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||
| High | 8.7 | CVE-2026-93858 |
In OpenStack Mistral through 23.0.0, the std.ssh_proxied action passes a caller-supplied proxy_command value directly to paramiko.ProxyCommand() before any SSH connection to a...
OpenStackOpenStack Mistral
|
NVD | |||
|
CVE-2026-93858In OpenStack Mistral through 23.0.0, the std.ssh_proxied action passes a caller-supplied proxy_command value directly to paramiko.ProxyCommand() before any SSH connection to a...
From the advisoryIn OpenStack Mistral through 23.0.0, the std.ssh_proxied action passes a caller-supplied proxy_command value directly to paramiko.ProxyCommand() before any SSH connection to a gateway or target host is attempted. An authenticated project member can use the standard action-execution API to submit an arbitrary local command as proxy_command; paramiko starts that command as a subprocess on the executor host under the executor's own service account, independent of whether the SSH connection itself ever succeeds. Only Mistral deployments that permit the std.ssh_proxied action, the default configuration, are affected. Impact if exploitedConfidentialityHigh IntegrityHigh AvailabilityHigh
How it is exploited
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:L/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X Affects
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||
| Medium | 6.1 | CVE-2026-107363 |
In OpenStack Zaqar before 23.0.1, the WebSocket transport fails to bind the project identifier in subsequent requests to the project authenticated by the Keystone token
OpenStackOpenStack Zaqar
|
NVD | |||
|
CVE-2026-107363In OpenStack Zaqar before 23.0.1, the WebSocket transport fails to bind the project identifier in subsequent requests to the project authenticated by the Keystone token
From the advisoryIn OpenStack Zaqar before 23.0.1, the WebSocket transport fails to bind the project identifier in subsequent requests to the project authenticated by the Keystone token. An authenticated user with a valid token for one project may substitute another project's UUID to enumerate, inspect, create, or delete queues belonging to that project, resulting in unauthorized disclosure, modification, or loss of queue data. Only deployments using the WebSocket transport with Keystone authentication are affected. Impact if exploitedConfidentialityLow IntegrityHigh AvailabilityHigh
How it is exploited
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X Affects
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||