OpenStack Open source software for creating private and public clouds
Don't miss out!
Thousands of developers use stack.watch to stay informed.Get an email whenever new security vulnerabilities are reported in any OpenStack product.
RSS Feeds for OpenStack security vulnerabilities
Create a CVE RSS feed including security vulnerabilities found in OpenStack products with stack.watch. Just hit watch, then grab your custom RSS feed url.
Products by OpenStack Sorted by Most Security Vulnerabilities since 2018
By the Year
In 2026 there have been 61 vulnerabilities in OpenStack with an average score of 6.7 out of ten. Last year, in 2025 OpenStack had 1 security vulnerability published. That is, 60 more vulnerabilities have already been reported in 2026 as compared to last year. Last year, the average CVE base score was greater by 0.79
| Year | Vulnerabilities | Average Score |
|---|---|---|
| 2026 | 61 | 6.71 |
| 2025 | 1 | 7.50 |
| 2024 | 7 | 6.00 |
| 2023 | 13 | 5.45 |
| 2022 | 10 | 5.99 |
| 2021 | 6 | 7.40 |
| 2020 | 8 | 8.00 |
| 2019 | 13 | 8.58 |
| 2018 | 13 | 6.93 |
It may take a day or so for new OpenStack vulnerabilities to show up in the stats or in the list of recent security vulnerabilities. Additionally vulnerabilities may be tagged under a different product or component name.
Recent OpenStack Security Vulnerabilities
| CVE | Date | Vulnerability | Products |
|---|---|---|---|
| CVE-2026-51772 | Sep 25, 2026 |
OpenStack Glance SSRF via Image API v2 show_multiple_locationsA Server-Side Request Forgery (SSRF) vulnerability exists in the Image API (v2) of OpenStack Glance. When the show_multiple_locations configuration option is enabled in glance-api.conf, an authenticated attacker can manipulate the locations attribute of an image in the queued state by sending a crafted HTTP PATCH request |
|
| CVE-2026-97404 | Sep 24, 2026 |
OpenStack Zaqar WSGI URLSignature Header Bypass (before 22.0.2)In OpenStack Zaqar before 22.0.2, WSGI transport mishandles the URL-Signature header. By sending a request with an empty URL-Signature header, an unauthenticated remote attacker who knows a target project's UUID may bypass both Keystone authentication and pre-signed URL verification, resulting in the ability to read, enumerate, create, and delete that project's queues, messages, claims, and subscriptions. By additionally claiming an administrative role, the attacker may also perform administrative operations, such as managing pools and flavors in admin_mode deployments. Only deployments using the WSGI transport with an authentication strategy configured are affected; the websocket transport is not affected. |
|
| CVE-2026-97149 | Sep 24, 2026 |
OpenStack Swift <2.38.2 TempURL X-Copy-From Header BypassIn OpenStack Swift before 2.38.2, the tempurl middleware does not reject the X-Copy-From header on PUT requests. A TempURL signature only covers the method, expiry, and path, and thus the list of disallowed headers is the only defense against a signed PUT request changing what the request does. An attacker holding a PUT TempURL for a single object can add an X-Copy-From header naming any object in the same account; the copy middleware copies that object to the destination, and the attacker then reads the victim's data back with a GET TempURL for the destination object. Copies across account boundaries are rejected. Only deployments using the shipped default proxy pipeline (tempurl and copy middleware) with account-level TempURL keys are affected. |
|
| CVE-2026-94572 | Sep 21, 2026 |
OpenStack Octavia <18.0.1 Amphora TLS Cipher Injection (HAProxy Config)In OpenStack Octavia before 18.0.1, the Amphora provider driver did not validate the listener and pool tls_ciphers field for control characters. The value is written verbatim into the HAProxy configuration generated on the amphora, and thus an authenticated project member who owns a TLS-enabled load balancer can embed a newline and inject arbitrary HAProxy configuration directives. Only deployments using the Amphora provider are affected. |
|
| CVE-2026-94571 | Sep 21, 2026 |
OpenStack Octavia <18.0.1 L7 Policy Redirect URL Control char InjectionIn OpenStack Octavia before 18.0.1, the Amphora provider driver did not reject control characters in the L7 policy redirect_url and redirect_prefix fields. The RFC 3986 URL validator percent-encodes control characters before validating, and thus newlines passed structural checks, but Octavia stored and wrote the raw unencoded value directly into the HAProxy configuration generated on the amphora. An authenticated project member who owns a load balancer can therefore inject arbitrary HAProxy directives through a REDIRECT_TO_URL L7 policy. Only deployments using the Amphora provider are affected. |
|
| CVE-2026-93854 | Sep 18, 2026 |
OpenStack Blazar <17.0.1 Object-Level Authorization Bypass in Lease APIIn OpenStack Blazar before 17.0.1, the V2 lease API does not enforce object-level authorization on its update and delete operations (PUT /v2/leases/{lease_id} and DELETE /v2/leases/{lease_id}). The policy authorize() wrapper attempts to load the target lease to build the authorization target from its owner, but it looks up the lease under the keyword "lease_id" whereas the controller methods name the parameter "id" (and the wsme_pecan.wsexpose wrapper delivers it positionally). The lookup returns None, and thus authorization falls back to the requesting user's own project_id/user_id instead of the target lease owner. Any authenticated user who knows a lease ID can therefore modify or delete leases belonging to other users and projects, bypassing the intended ownership check. |
|
| CVE-2026-93852 | Sep 18, 2026 |
OpenStack Blazar <17.0.1: Lease Enumeration & Auth Bypass via GET /v2/leasesIn OpenStack Blazar before 17.0.1, the V2 lease listing operation (GET /v2/leases) returns leases for every project without enforcing project scoping or an administrator-only policy. Any authenticated user with access to the Blazar REST API can enumerate leases belonging to other tenants, exposing lease IDs, reservation IDs, resource IDs, and reservation metadata. The exposed lease IDs also enable the object-level authorization bypass tracked in the companion request, allowing an attacker to then modify or delete the enumerated leases. |
|
| CVE-2026-71198 | Sep 14, 2026 |
OpenStack Glance <32.0.1: Unvalidated Host in HTTP Location APIIn OpenStack Glance before 32.0.1, the location API does not validate destination hosts when adding an HTTP location to an image. Unlike the web-download import path, the location API only checks the URL scheme and does not apply the import_filtering_opts host restrictions. An authenticated user can add a location pointing to internal endpoints such as the cloud metadata service (169.254.169.254), and retrieve the response by downloading the image data. This affects both the new POST /v2/images/{id}/locations API and the old PATCH API when show_multiple_locations is enabled. Deployments with the HTTP store backend enabled are affected. |
|
| CVE-2026-90461 | Sep 11, 2026 |
OpenStack Ironic <=38.0.0 leaks creds to remote host via HTTP AuthOpenStack Ironic through 38.0.0 may send a username and password to an unexpected remote host when Image Service is configured for HTTP(S) Basic Authentication. |
|
| CVE-2026-90460 | Sep 11, 2026 |
OpenStack Keystone <29.0.3 Credential API Priv Escalation via Delegated TokensAn issue was discovered in OpenStack Keystone before 29.0.3. Tokens obtained via delegated authentication methods (EC2 credentials, application credentials, OAuth1 access tokens, and trusts) are not blocked from creating, modifying, or deleting credentials via the /v3/credentials API. EC2-derived tokens can additionally read credential blobs, exposing TOTP MFA seeds and other secrets. Also, PATCH /v3/credentials does not validate the requested post-update project_id, allowing any delegated token to move a credential to an unauthorized project. All Keystone deployments using delegated authentication are affected. |
|
| CVE-2026-80183 | Aug 26, 2026 |
OpenStack Keystone <29.0.3: Auth Role Harvest via GET /role_assignmentsIn OpenStack Keystone before 29.0.3, any authenticated user holding role:reader on any project can list every project-scoped role assignment under any domain by passing a domain ID as scope.project.id with include_subtree to the GET /v3/role_assignments endpoint. The domain's project record has domain_id=null, causing the policy domain_id check to pass for any caller. With include_names, the response discloses the names and home-domain IDs of every user, group, project, and role involved. The literal "default" domain ID works against any deployment created with keystone-manage bootstrap. An attacker can harvest domain IDs from the response and repeat the query to map role assignments across the entire cloud. This is caused by misuse of "None" in list_role_assignments_for_tree. |
|
| CVE-2026-80184 | Aug 25, 2026 |
OpenStack Keystone <29.0.3: Delegated Auth Token Scope EscalationIn OpenStack Keystone before 29.0.3, tokens obtained via delegated authentication mechanisms (OAuth1 access tokens, application credentials, trusts) could be submitted to the token-method authentication path for reauthentication to escape their intended project scope. When an application credential token was presented with no explicit scope, Keystone would issue a new token scoped to the credential owner's default project rather than the project for which the credential was issued, bypassing the intended project boundary. All Keystone deployments that permit delegated authentication through OAuth1 access tokens, application credentials, or trusts are affected. |
|
| CVE-2026-80182 | Aug 25, 2026 |
OpenStack Keystone <29.0.3 OAuth1 Delegation PrivEscIn OpenStack Keystone before 29.0.3, tokens obtained via OAuth1 access token, application credential, or trust-scoped authentication could create new long-lived credentials or authorize new delegations that persist independently of, and outlive, the credential used to obtain them. The delegation restrictions that block these operations did not consistently apply to all delegated token types, allowing an OAuth1-scoped token, for example, to create application credentials or authorize OAuth1 request tokens despite those operations being restricted for other delegated token types. All Keystone deployments that permit delegated authentication through OAuth1 access tokens, application credentials, or trusts are affected. |
|
| CVE-2026-77648 | Aug 20, 2026 |
OpenStack Glance < 32.0 SSRF via /v2/tasks Import APIIn OpenStack Glance through 32.0.0, the /v2/tasks API accepts type=import tasks that bypass import_filtering_opts, allowing an admin to fetch internal URLs from the Glance service network (aka SSRF), as long as https:// or http:// is used. This API has been available only to admins since Xena, and it has been deprecated for several releases. |
|
| CVE-2026-76878 | Aug 19, 2026 |
OpenStack Aodh API Bypass Project Scoping (pre 22.0.1)In OpenStack Aodh before 22.0.1, the alarm list API bypasses project scoping when the all_projects query parameter is set to false. The API checks for the presence of the all_projects key rather than its value; a true value enforces the administrator-only policy, but a false value removes the key and skips the branch that normally restricts results to the caller's project. A non-admin user with the reader role can list alarms from all projects, exposing alarm actions containing trust webhook URLs, Heat signal endpoints, project IDs, and user IDs. The parameter can also be combined with a foreign project_id to target a specific project's alarms. A related concern is that OpenStack Watcher does not apply authorization to its webhook trigger endpoint. Any authenticated user who learns an audit's webhook URL, for example from this leaked Aodh alarm metadata, can start an EVENT audit and its associated action plan regardless of their own project or role. The webhook endpoint has lacked policy enforcement since its introduction in the Ussuri release (Watcher 4.0.0). |
|
| CVE-2026-74250 | Aug 14, 2026 |
OpenStack Ironic <38.0.1 - Autodetect Deploy Cleaning FailureIn OpenStack Ironic before 38.0.1, the autodetect deploy interface may fail to run cleaning immediately after enrollment with, or changing to, the autodetect deploy interface. |
|
| CVE-2026-74248 | Aug 14, 2026 |
OpenStack Octavia QoS Auth Bypass before 18.0.0 (prevents QoS policy deletion)OpenStack Octavia through 18.0.0 mishandles quality of service (QoS) policy authorization. By associating another project's QoS policy with an amphora, an authenticated user may prevent deletion of that policy. All Octavia deployments are affected. |
|
| CVE-2026-71194 | Aug 12, 2026 |
OpenStack Designate mDNS Pool-Blind Lookup (before 22.0.2)In OpenStack Designate before 22.0.2, the mDNS handler performs pool-blind lookups when resolving record queries and NOTIFY requests. When two zones with the same name exist across different pools, the lookup fails with a deterministic error, causing the handler to return REFUSED for all DNS queries through that path. The _handle_notify path is exploitable via a single unauthenticated UDP packet. This is independently reachable through the cross-tenant zone overlap described in a different recent CVE, and also affects legitimate same-tenant cross-pool configurations. BIND9 views do not mitigate this issue as mDNS is a shared service upstream of any view configuration. |
|
| CVE-2026-71193 | Aug 12, 2026 |
OpenStack Designate before 22.0.1 Cross-Tenant DNS Hijack via AttributeFilterIn OpenStack Designate before 22.0.1, zone creation checks (_is_subzone, _is_superzone, and the duplicate-zone DB constraint) are scoped to the target pool only. An authenticated user can bypass these checks by scheduling a zone to a different pool via the AttributeFilter scheduler, creating an overlapping zone that conflicts with another tenant's zone. This enables cross-tenant DNS hijack (redirecting traffic to attacker-controlled IPs) and DNS denial of service (NODATA responses). Exploitation requires a multi-pool deployment with AttributeFilter enabled in scheduler_filters, which is a non-default but documented and supported configuration for self-service tiering. |
|
| CVE-2026-71201 | Aug 05, 2026 |
OpenStack Ironic 38.0.0 Info Disclosure: crossproj PortgroupsIn OpenStack Ironic through 38.0.0, a project reader that makes a crafted request to Ironic can return Portgroups assigned to Nodes owned or leased by another project. |
|
| CVE-2026-71192 | Aug 05, 2026 |
OpenStack Swift S3API s3_acl=true header injection bypass (2.38.0)In OpenStack Swift through 2.38.0, the S3API middleware does not sanitize Swift-native control headers (X-Copy-From, X-Copy-From-Account) from S3 API requests when s3_acl=true. An attacker can inject these headers into a signed PUT request targeting their own bucket, causing Swift to perform a server-side copy from another tenant's private object. The source object authorization is bypassed because the S3API middleware has already authorized the request against the destination. The attacker can read any object whose project_id, container name, and object name are known, regardless of the source object's ACLs or ownership. This requires the non-default s3_acl=true configuration. |
|
| CVE-2026-71191 | Aug 05, 2026 |
OpenStack Swift 2.38.0 S3API SigV4 Header Injection (CVE-2026-71191)In OpenStack Swift through 2.38.0, S3API middleware does not enforce that semantic x-amz-* headers are covered by the SigV4 signature on presigned URL requests. An attacker who obtains a presigned PUT URL can inject an unsigned X-Amz-Copy-Source header, causing Swift to perform a server-side copy from an arbitrary source object using the signer's authorization context. The attacker can read any object the signer has access to, provided the target project_id, container name, and object name are known. This affects all deployments using the default s3_acl=false configuration. |
|
| CVE-2026-71190 | Aug 05, 2026 |
OpenStack Swift 2.38.0 ReDoS in Proxy Accept Header Parser (CVE-2026-71190)In OpenStack Swift through 2.38.0, the proxy server Accept header parser contains a regular expression vulnerable to catastrophic backtracking (ReDoS). The "qdtext" pattern (?:[^"]|\\.)* allows an unauthenticated remote attacker to send a crafted Accept header that causes exponential CPU consumption in the proxy worker. A payload of 32 backslash-character pairs exceeds 30 seconds of CPU time. No authentication is required. Repeated requests can exhaust all proxy worker threads, resulting in a complete denial of service. |
|
| CVE-2026-55707 | Aug 05, 2026 |
Neutron Subnet Onboarding Auth Bypass (v<28.0.2)In OpenStack Neutron before 28.0.2, the subnetpool onboarding API does not verify ownership of the target subnets. An authenticated user can onboard subnets from another project's shared network into their own subnetpool, mutating the victim's subnet state and altering L3 routing and address scope behavior for victim routers. |
|
| CVE-2026-66139 | Jul 24, 2026 |
OpenStack Zaqar <22.0.0 Authentication Bypass via EXTRA-SPEC HeaderOpenStack Zaqar through 22.0.0 allows authentication bypass via an EXTRA-SPEC header when a UUID is known. |
|
| CVE-2026-66138 | Jul 24, 2026 |
CVE-2026-66138: Ironic-Python-Agent pre-11.6.0 ntp_server shell execIn OpenStack Ironic Python Agent through 11.6.0, a project-scoped user with the manager role can achieve arbitrary code execution on a running Ironic-Python-Agent via a maliciously constructed configuration, because the value of ntp_server is passed to a shell. |
|
| CVE-2026-54422 | Jul 24, 2026 |
OpenStack Ironic Python Agent 11.5.0 Credential Leak in bootcIn OpenStack Ironic Python Agent through 11.5.0, a malicious bootc container, when deployed using ironic-python-agent, may be able to extract the credentials used to download it. |
|
| CVE-2026-54423 | Jul 10, 2026 |
OpenStack Ironic <37.0.1 IPMI send_raw RCEIn OpenStack Ironic before 37.0.1, an Ironic user with the ability to deploy nodes using the IPMI management interface can maliciously use the send_raw step to send arbitrary IPMI commands to a node, bypassing Ironic's access control. |
|
| CVE-2026-44918 | Jul 10, 2026 |
OpenStack Ironic <37.0.1: Cross-Project Node Creation/Modification BypassOpenStack Ironic through before 37.0.1 allows creation or modification of nodes cross-project without authorization. |
|
| CVE-2026-50221 | Jun 23, 2026 |
OpenStack Swift <2.37.2 SSRF via Authenticated Header InjectionIn OpenStack Swift before 2.37.2, proxy-server does not strip internal update headers (X-Container-Host, X-Container-Device, X-Delete-At-Host, X-Delete-At-Device) from client requests before forwarding them to object-servers. An authenticated user with write access can inject these headers to redirect container update requests to an attacker-controlled server, enabling server-side request forgery. The SSRF requests expose internal cluster metadata including storage policy indexes, partition mappings, device names, and when at rest encryption is enabled, cipher text and initialization vectors for the container-level encryption key. The attacker can also cause "ghost listings" in arbitrary containers via the shard-range redirect mechanism. |
|
| CVE-2026-55748 | Jun 17, 2026 |
OpenStack Horizon <25.7.4 RC file script download may exec shell metaOpenStack Horizon before 25.7.4 produces scripts for OpenStack RC file downloading that may have a crafted project name with shell metacharacters. NOTE: some parties consider this a security hardening opportunity to address certain types of user error, not a vulnerability. |
|
| CVE-2026-46448 | Jun 16, 2026 |
OpenStack Nova <33.0.2: Server Create API Misses Placement AllocIn OpenStack Nova before 33.0.2, the server create API does not strip certain hint data. The resulting instance has no Placement allocation. |
|
| CVE-2026-54421 | Jun 14, 2026 |
OpenStack Ironic 35.0.1: PATCH on volume props leaks iSCSI credsIn OpenStack Ironic before 37.0.1, when applying a PATCH to update fields in volume properties the user is authorized for, Ironic can return unredacted sensitive information (such as iSCSI credentials). The PATCH outcome is a security issue; the POST outcome is not a security issue. |
|
| CVE-2026-50589 | Jun 04, 2026 |
Unauth Service Crash via Crafted JSON in OpenStack Ironic 32-35.0.1In OpenStack Ironic 32 before 37.0.0, an unauthenticated malicious user could submit a crafted JSON string to some endpoints on the API or JSON-RPC service and effect a service crash. |
|
| CVE-2026-50266 | Jun 04, 2026 |
OpenStack Neutron Shared Net Port Spoofing via Project Manager RBAC (28.0.1)In OpenStack Neutron before 28.0.1, a project manager can create or update a port on a shared network owned by another project and set device_owner to a value that has "network:" at the beginning ("network:dhcp" for example). The default port RBAC policies incorrectly included PROJECT_MANAGER without requiring network ownership, allowing any project manager to obtain trusted network-service port behavior on shared networks. Depending on backend and deployment, this can bypass anti-spoofing and security group protections, enabling DHCP, MAC, or IP spoofing against other tenants on the shared network. This is a regression of CVE-2015-5240 (OSSA-2015-018). |
|
| CVE-2026-41283 | Jun 04, 2026 |
OpenStack Mistral RCE via API before 22.0.0OpenStack Mistral through 22.0.0 allows Arbitrary Remote Code Execution when the API is exposed. There are endpoints that allow code execution, which can lead to exfiltration of service credentials. |
|
| CVE-2026-44917 | Jun 04, 2026 |
OpenStack Ironic <35.0.2 Local File Read via PXE TemplateOpenStack Ironic before 35.0.2 allows a malicious authenticated project admin or manager to read local files on the Ironic conductor via a pxe_template. |
|
| CVE-2026-48681 | Jun 04, 2026 |
OpenStack Ironic <35.0.2: DT File Overwrite Vulnerability in ISO DeployerOpenStack Ironic through before 35.0.2 allows file overwrite via directory traversal during deployment with a crafted ISO image. |
|
| CVE-2026-46447 | Jun 03, 2026 |
OpenStack Ironic <=35.0.x Boot Script InjectionOpenStack Ironic before 35.0.2 allows Boot Script Injection of an iPXE script if the attacker can set node.driver_info or node.instance_info. |
|
| CVE-2026-49299 | May 28, 2026 |
OpenStack Neutron <28.0.1 Plural Action Mismatch Enables Unauthorized TaggingIn OpenStack Neutron before 28.0.1, the tagging controller enforces plural policy action names on single-tag write operations while the defined policy rules use singular names. The mismatched names evaluate as allowed under the default policy, permitting a project reader to create and update tags on same-project resources. Deployments running Neutron 26.0.0 or later are affected. |
|
| CVE-2026-44394 | May 28, 2026 |
OpenStack Keystone <29.0.2: Rescope Token Exploit to Bypass ExpiryAn issue was discovered in OpenStack Keystone before 29.0.2. The Keystone federated token rescoping mechanism does not propagate the original token's expiry to the newly issued token. When a federated user rescopes a token via POST /v3/auth/tokens, the handle_scoped_token() function in the mapped authentication plugin returns response data without an expires_at value. The token provider falls back to issuing a token with a fresh default TTL. By rescoping repeatedly before each token expires, a user can maintain access indefinitely, bypassing operator-configured token lifetime policies. This is a variant of CVE-2012-3426. Only deployments using federated identity (SAML2, OpenID Connect) are affected. |
|
| CVE-2026-43000 | May 28, 2026 |
OpenStack Keystone Pre-29.0.2 Priv Esc via Impersonation + TrustAn issue was discovered in OpenStack Keystone before 29.0.2. When combined with an application credential impersonation vulnerability, an attacker with the member role on a project can escalate to admin by chaining unrestricted application credentials with Keystone trusts. The impersonated token carries the victim's identity, which passes the trustor validation check. Keystone then validates the delegated roles against the victim's actual role assignments in the database, not the roles on the requesting token. This allows the attacker to create a trust delegating the victim's admin role to themselves. The trust persists independently, and additional trusts and application credentials can be created to maintain access. All actions are logged under the victim's identity. |
|
| CVE-2026-42999 | May 28, 2026 |
OpenStack Keystone RBAC Bypass via Untrusted JSON Merge (pre-29.0.2)An issue was discovered in OpenStack Keystone before 29.0.2. The Keystone RBAC policy enforcer in enforce_call unconditionally merges the raw JSON request body into the policy enforcement dictionary via policy_dict.update(json_input.copy()), overwriting trusted target data that was previously set from database lookups. Because flask.request.get_json is called with force=True, this works regardless of Content-Type or HTTP method. Any authenticated user can inject arbitrary policy target attributes (e.g., user_id, project_id) into the request body to bypass RBAC checks and perform unauthorized operations on resources belonging to other users or projects. This was introduced in commit 5ea59f52 (Rocky/14.0.0). |
|
| CVE-2026-42998 | May 28, 2026 |
Keystone Auth Plugin Priv Escalation before 29.0.2An issue was discovered in OpenStack Keystone before 29.0.2. The Keystone application credential authentication plugin does not verify that the user supplied in the authentication request matches the owner of the application credential. An attacker can authenticate with their own application credential ID and secret while specifying a different user's name and domain in the request body. Keystone issues a token attributed to the victim user. The impersonated token is project-scoped and carries the intersection of the application credential's roles and the victim's actual roles on the project. This enables audit evasion, reading the victim's credentials, and acting as the victim within shared projects. |
|
| CVE-2026-49017 | May 27, 2026 |
OpenStack Swift s3api infinite loop causes DoS (pre 2.36.2/2.37.2)In OpenStack Swift before 2.36.2 and 2.37.2, s3api middleware enters an infinite loop when processing a truncated aws-chunked PUT request body. The StreamingInput class repeatedly appends an empty buffer and re-reads, causing the proxy-server worker handling the request to become permanently unresponsive with increasing CPU and memory consumption. An authenticated attacker can systematically exhaust all proxy-server workers, resulting in denial of service. The defect was introduced in Swift 2.36.0. |
|
| CVE-2026-44919 | May 14, 2026 |
OpenStack Ironic Infinite Loop via file:///dev/zero URLIn OpenStack Ironic through 35.x before a3f6d73, during image handling, an infinite loop in checksum calculations can occur via the file:///dev/zero URL. |
|
| CVE-2026-44916 | May 08, 2026 |
OpenStack Ironic ks_template unsandboxed renderingIn OpenStack Ironic before 35.0.2 (in a certain non-default configuration), instance_info['ks_template'] is rendered without sandboxing. |
|
| CVE-2026-40214 | May 07, 2026 |
OpenStack Cyborg <16.0.1: ARQ API Cross-Tenant DoS VulnerabilityIn OpenStack Cyborg before 16.0.1, the Accelerator Request (ARQ) API does not enforce project ownership at any layer. The project_id column in the database is never populated (NULL for every ARQ), database queries have no project filtering, and policy checks are self-referential (the authorize_wsgi decorator compares the caller's project_id with itself rather than the target resource). Any authenticated non-admin user can complete various actions such as deleting ARQs bound to other projects' instances, aka cross-tenant denial of service. |
|
| CVE-2026-40213 | May 07, 2026 |
OpenStack Cyborg <=16.0.1 Unauthenticated Policy Bypass via Rule:allow (@)OpenStack Cyborg before 16.0.1 uses rule:allow (check_str='@') as the default policy for multiple API endpoints. This unconditionally authorizes any request carrying a valid Keystone token regardless of roles, project membership, or scope. An authenticated user with zero role assignments can complete various actions such as reprogramming FPGA bitstreams on arbitrary compute nodes via agent RPC. |
|
| CVE-2026-42997 | May 05, 2026 |
OpenStack Ironic idrac Remote Credential Exposure <=35.0.1An issue was discovered in idrac in OpenStack Ironic before 35.0.1. During import, a user invoking molds can request authorization to be sent to a remote endpoint. The credential forwarded is a time-limited Keystone token (which provides access to all OpenStack services Ironic is authorized for); or basic credentials configured for molds storage. The fixed versions are 26.1.6, 29.0.5, 32.0.1, and 35.0.1. |
|