OpenStack Nova CVE-2026-46448

Requires valid authenticated access to the OpenStack Identity/Nova API at a privilege level able to call the server-create (boot instance) endpoint and supply scheduler hint data (consistent with CVSS PR:L) - i.e., an ordinary tenant/project member, not necessarily an admin. The specific trigger is submitting the 'certain hint data' that the create API fails to strip, which causes the resulting instance to be provisioned with no Placement allocation. Limiting factors: the attacker must already possess project credentials and API reachability, the impact is resource-accounting/availability rather than direct code execution or data theft, and the deployment must be running an unpatched Nova in the 18.0.0-31.3.1, 32.0.0-32.2.1, or 33.0.0-33.0.2 ranges; exploitation is not automatable per SSVC and yields only partial technical impact.

Signals are mixed-to-moderate. The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:L/A:H, base 8.5) indicates a low-privilege, network-reachable, low-complexity issue whose primary impact is availability (A:H) with a scope change (S:C), consistent with one tenant's actions degrading shared infrastructure. EPSS is low (0.26%, 17th percentile) and SSVC marks it Automatable: no with only partial technical impact, so widespread opportunistic exploitation is unlikely; this reads as a resource-integrity/availability bug exploitable by an insider or a holder of valid project credentials rather than an internet-facing RCE. Note a data conflict to verify: the input Tags say 'Information Disclosure,' but the CVSS vector sets C:N (no confidentiality impact) and the description describes a Placement-allocation/accounting failure - the 'Information Disclosure' tag is not supported by the vector and should be treated with caution. There is no CISA KEV listing in the data, so this is not confirmed actively exploited.

A user holding valid credentials for any project on the cloud calls the Nova server-create API with crafted scheduler hint data that is not stripped, causing Nova to boot the instance while skipping creation of its Placement allocation. The attacker repeats this to launch VMs that consume real CPU, memory, and disk invisibly to the scheduler's accounting, eventually exhausting a compute host and degrading or denying service to other tenants' workloads. SSVC rates exploitation as proof-of-concept and not automatable, so this is a hands-on abuse rather than a mass-scannable exploit.