OpenStack Octavia CVE-2026-74248

Exploitation requires an authenticated OpenStack account with at minimum tenant-level privileges to create or modify amphorae in at least one project (CVSS PR:L confirmed). The attacker must know a valid QoS policy UUID from a target project; discoverability depends on whether the OpenStack deployment permits cross-project QoS policy listing via the Neutron API - if it does, enumeration is straightforward, but if scoped to own-project only, UUID must be obtained through other means. No non-default configuration or special deployment mode is required - the advisory states all Octavia deployments are affected, indicating this is a default-state flaw. Exploitation is strictly limited in impact: it blocks deletion of the victim's QoS policy but grants no read access to data, no modification of traffic, and no service disruption. Trusted single-tenant environments and deployments with strict oslo.policy controls on QoS association operations significantly limit practical exploitability.

The CVSS 4.3 vector AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N correctly characterizes this as low-complexity, network-accessible, authenticated exploitation with only partial integrity impact and zero confidentiality or availability loss. No EPSS data was supplied, the vulnerability does not appear in the CISA KEV catalog, and no public exploit code has been identified - exploitation probability is speculative rather than empirically measured. The practical threat model is disruptive to multi-tenant operators: a malicious or compromised tenant can persistently lock another project's QoS policy, impeding network management without gaining any data access. Even a mid-sized municipal IT team in ustka running a private OpenStack deployment should treat this as a tenant-isolation concern worth scheduling into normal patch cycles, though it carries no urgency comparable to RCE or credential-exposure flaws. For public cloud operators serving untrusted tenants the isolation breach is more operationally significant; single-tenant private clouds where all users are trusted face negligible real-world risk.

An authenticated tenant user on a shared OpenStack cloud obtains the UUID of a QoS policy belonging to a separate project - potentially through API enumeration if list permissions are permissive, or through prior knowledge. The attacker calls the Octavia API to associate that foreign QoS policy UUID with an amphora in their own project. When the legitimate QoS policy owner later attempts to delete their policy via the Neutron API, the deletion is rejected because Octavia's dependency tracking treats the cross-project association as an active reference, leaving the victim unable to manage or remove the resource.