A Server-Side Request Forgery (SSRF) vulnerability exists in the Image API (v2) of OpenStack Glance. When the showmultiplelocations 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

In OpenStack Octavia before 18.0.1, the Amphora provider driver did not validate the listener and pool tlsciphers 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.

In 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.

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 adminmode deployments. Only deployments using the WSGI transport with an authentication strategy configured are affected; the websocket transport is not affected.

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.

======================================================================= OSSA-2026-042: Zaqar empty URL-Signature header bypasses authentication =======================================================================

:Date: September 24, 2026 :CVE: CVE-2026-97404

Affects ~~~~~~~ - Zaqar: >=1.0.0 <20.1.2, >=21.0.0 <21.0.2, >=22.0.0 <22.0.2

Description ~~~~~~~~~~~ pple, an independent security researcher, reported that Zaqar's WSGI transport mishandles an empty URL-Signature header: a request carrying the header with an empty value bypasses both Keystone authentication and pre-signed URL verification. An unauthenticated remote attacker who knows a target project's UUID can then 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 adminmode deployments. Only deployments using the WSGI transport with an authentication strategy configured are affected; the websocket transport is not affected.

Patches ~~~~~~~ - https://review.opendev.org/1007162 (2025.1/epoxy) - https://review.opendev.org/1007161 (2025.2/flamingo) - https://review.opendev.org/1007160 (2026.1/gazpacho) - https://review.opendev.org/1007159 (2026.2/hibiscus) - https://review.opendev.org/1007158 (2027.1/indri (development))

Credits ~~~~~~~ - pple from Independent (CVE-2026-97404)

References ~~~~~~~~~~ - https://launchpad.net/bugs/2164987 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-97404

Notes ~~~~~ - This issue is distinct from the EXTRA-SPEC header bypass in OSSA-2026-029; the fix for that issue removed the EXTRA-SPEC branch but left the empty-value handling of the URL-Signature header untouched.

-- Goutham Pacha Ravi OpenStack Vulnerability Management Team https://security.openstack.org/vmt.html

======================================================================= OSSA-2026-041: Cross-container information disclosure via Swift tempurl =======================================================================

:Date: September 24, 2026 :CVE: CVE-2026-97149

Affects ~~~~~~~ Description ~~~~~~~~~~~ Oren Yomtov from ACT Security and "swdb", a security researcher, independently reported a vulnerability in the Swift tempurl middleware. A party holding a single-object PUT TempURL signed with an account-level key (X-Account-Meta-Temp-URL-Key) could resend the signed request with an X-Copy-From header naming any object in the same account, causing Swift to copy the named object into the granted destination object, and read the copied bytes back with a second GET TempURL, disclosing objects the holder of the TempURL was not authorized to access. Only deployments with the tempurl middleware enabled are affected. The copy is limited to the account that owns the key, and the attacker must know the target container and object name.

As a mitigation, operators can add x-copy-from to the incomingremoveheaders option of the [filter:tempurl] section of their proxy server configuration. With that configuration the header is silently removed and the PUT stores no data; the patches below instead reject the request with a 400 response.

Patches ~~~~~~~ - https://review.opendev.org/1007050 (2025.1/epoxy) - https://review.opendev.org/1007049 (2025.2/flamingo) - https://review.opendev.org/1007048 (2026.1/gazpacho) - https://review.opendev.org/1007047 (2026.2/hibiscus) - https://review.opendev.org/1007046 (2027.1/indri (development))

Credits ~~~~~~~ - Oren Yomtov from ACT Security - swdb from Independent

References ~~~~~~~~~~ - https://launchpad.net/bugs/2166876 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-97149

Notes ~~~~~ - This issue is distinct from the S3API vulnerabilities in OSSA-2026-030; it affects the native Swift API with the default proxy pipeline and does not require the S3API middleware or the s3acl configuration.

-- Goutham Pacha Ravi OpenStack Vulnerability Management Team https://security.openstack.org/vmt.html

In 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 importfilteringopts 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 showmultiplelocations is enabled. Deployments with the HTTP store backend enabled are affected.

An 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 projectid, allowing any delegated token to move a credential to an unauthorized project. All Keystone deployments using delegated authentication are affected.

OpenStack 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.

In 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.

In 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/{leaseid} and DELETE /v2/leases/{leaseid}). 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 "leaseid" whereas the controller methods name the parameter "id" (and the wsmepecan.wsexpose wrapper delivers it positionally). The lookup returns None, and thus authorization falls back to the requesting user's own projectid/userid 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.

In OpenStack Octavia before 18.0.1, the Amphora provider driver did not reject control characters in the L7 policy redirecturl and redirectprefix 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 REDIRECTTOURL L7 policy. Only deployments using the Amphora provider are affected.

========================================================================================== ==========================================================================================

:Date: September 21, 2026 :CVE: CVE-2026-94572, CVE-2026-94571

Affects ~~~~~~~ - Octavia: >=0.8.0 <16.1.0, ==17.0.0, ==18.0.0

Description ~~~~~~~~~~~ Chen YuXiang from the Institute of Computing Technology, Chinese Academy of Sciences reported input validation flaws in the Octavia load balancer API. The listener and pool tlsciphers fields and the L7 policy redirecturl and redirectprefix fields were written into the HAProxy configuration generated on the amphora without rejecting control characters, allowing an authenticated user who owns a load balancer managed by OpenStack Octavia's Amphora provider to inject arbitrary HAProxy configuration directives.

Subsequently, an independent reporter, "Rolix", demonstrated that these flaws can be exploited to execute arbitrary commands as root on the provider-managed amphora, to disclose other tenants' TLS private keys and certificates and the deployment heartbeat key stored on the amphora, and to reach the control-plane network to which the amphora is attached.

Only the Amphora provider driver is affected. Deployments that use a different provider driver do not render tenant input into an HAProxy configuration and are not affected.

Errata ~~~~~~ Patches ~~~~~~~ - https://review.opendev.org/1001096 (2025.1/epoxy) - https://review.opendev.org/1001097 (2025.1/epoxy) - https://review.opendev.org/1001094 (2025.2/flamingo) - https://review.opendev.org/1001095 (2025.2/flamingo) - https://review.opendev.org/1001091 (2026.1/gazpacho) - https://review.opendev.org/1001092 (2026.1/gazpacho) - https://review.opendev.org/999553 (2026.2/hibiscus) - https://review.opendev.org/999555 (2026.2/hibiscus)

Credits ~~~~~~~ - "Rolix" from Independent (CVE-2026-94572)

References ~~~~~~~~~~ - https://launchpad.net/bugs/2167565 - https://launchpad.net/bugs/2162101 - https://launchpad.net/bugs/2162103 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-94572 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-94571

Notes ~~~~~ - Two changes are required on each branch: one fixes the tlsciphers fields and one fixes the L7 policy redirect fields. - The listener and pool tlsciphers fields were introduced in Octavia 6.0.0. Releases within the affected range that predate 6.0.0 are vulnerable only through the L7 policy redirecturl and redirectprefix fields. - These issues were originally triaged as a low-severity hardening opportunity and the fixes were developed and merged in public. They were reclassified after a proof of concept demonstrated remote code execution as root on the amphora and reachability of the control-plane network. - The remote code execution issue was reported to the OpenStack VMT by Thomas Goirand (zigo) of Infomaniak, on behalf of the reporter, "Rolix".

OSSA History ~~~~~~~~~~~~ - 2026-09-21 - Errata 1 - 2026-09-21 - Original Version

-- Goutham Pacha Ravi OpenStack Vulnerability Management Team https://security.openstack.org/vmt.html

On 9/21/26 10:08 AM, Goutham Pacha Ravi wrote: ========================================================================================== ==========================================================================================

:Date: September 21, 2026 :CVE: CVE-2026-pending,       CVE-2026-pending

Affects ~~~~~~~ - Octavia: >=0.8.0 <16.1.0, ==17.0.0, ==18.0.0

Description ~~~~~~~~~~~ Chen YuXiang from the Institute of Computing Technology, Chinese Academy of Sciences reported input validation flaws in the Octavia load balancer API. The listener and pool tlsciphers fields and the L7 policy redirecturl and redirectprefix fields were written into the HAProxy configuration generated on the amphora without rejecting control characters, allowing an authenticated user who owns a load balancer managed by OpenStack Octavia's Amphora provider to inject arbitrary HAProxy configuration directives.

Subsequently, an independent reporter, "Rolix", demonstrated that these flaws can be exploited to execute arbitrary commands as root on the provider-managed amphora, to disclose other tenants' TLS private keys and certificates and the deployment heartbeat key stored on the amphora, and to reach the control-plane network to which the amphora is attached.

Only the Amphora provider driver is affected. Deployments that use a different provider driver do not render tenant input into an HAProxy configuration and are not affected.

Patches ~~~~~~~ - https://review.opendev.org/1001096 (2025.1/epoxy) - https://review.opendev.org/1001097 (2025.1/epoxy) - https://review.opendev.org/1001094 (2025.2/flamingo) - https://review.opendev.org/1001095 (2025.2/flamingo) - https://review.opendev.org/1001091 (2026.1/gazpacho) - https://review.opendev.org/1001092 (2026.1/gazpacho) - https://review.opendev.org/999553 (2026.2/hibiscus) - https://review.opendev.org/999555 (2026.2/hibiscus)

Credits ~~~~~~~ - "Rolix" from Independent

References ~~~~~~~~~~ - https://launchpad.net/bugs/2167565 - https://launchpad.net/bugs/2162101 - https://launchpad.net/bugs/2162103 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-pending - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-pending

Notes ~~~~~ - Two changes are required on each branch: one fixes the tlsciphers   fields and one fixes the L7 policy redirect fields. - The listener and pool tlsciphers fields were introduced in   Octavia 6.0.0. Releases within the affected range that predate 6.0.0   are vulnerable only through the L7 policy redirecturl and   redirectprefix fields. - These issues were originally triaged as a low-severity hardening   opportunity and the fixes were developed and merged in public. They   were reclassified after a proof of concept demonstrated remote code   execution as root on the amphora and reachability of the control-plane   network. - The remote code execution issue was reported to the OpenStack VMT by   Thomas Goirand (zigo) of Infomaniak, on behalf of the reporter,   "Rolix". - CVE identifiers were requested from MITRE for these two   vulnerabilities on 2026-09-17. The CVEs will be added to this advisory   by errata once assigned.

-- Goutham Pacha Ravi OpenStack Vulnerability Management Team https://security.openstack.org/vmt.html

OpenStack 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.

========================================================================================== ==========================================================================================

:Date: September 21, 2026 :CVE: CVE-2026-pending, CVE-2026-pending

Affects ~~~~~~~ - Octavia: >=0.8.0 <16.1.0, ==17.0.0, ==18.0.0

Description ~~~~~~~~~~~ Chen YuXiang from the Institute of Computing Technology, Chinese Academy of Sciences reported input validation flaws in the Octavia load balancer API. The listener and pool tlsciphers fields and the L7 policy redirecturl and redirectprefix fields were written into the HAProxy configuration generated on the amphora without rejecting control characters, allowing an authenticated user who owns a load balancer managed by OpenStack Octavia's Amphora provider to inject arbitrary HAProxy configuration directives.

Subsequently, an independent reporter, "Rolix", demonstrated that these flaws can be exploited to execute arbitrary commands as root on the provider-managed amphora, to disclose other tenants' TLS private keys and certificates and the deployment heartbeat key stored on the amphora, and to reach the control-plane network to which the amphora is attached.

Only the Amphora provider driver is affected. Deployments that use a different provider driver do not render tenant input into an HAProxy configuration and are not affected.

Patches ~~~~~~~ - https://review.opendev.org/1001096 (2025.1/epoxy) - https://review.opendev.org/1001097 (2025.1/epoxy) - https://review.opendev.org/1001094 (2025.2/flamingo) - https://review.opendev.org/1001095 (2025.2/flamingo) - https://review.opendev.org/1001091 (2026.1/gazpacho) - https://review.opendev.org/1001092 (2026.1/gazpacho) - https://review.opendev.org/999553 (2026.2/hibiscus) - https://review.opendev.org/999555 (2026.2/hibiscus)

Credits ~~~~~~~ - "Rolix" from Independent

References ~~~~~~~~~~ - https://launchpad.net/bugs/2167565 - https://launchpad.net/bugs/2162101 - https://launchpad.net/bugs/2162103 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-pending - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-pending

Notes ~~~~~ - Two changes are required on each branch: one fixes the tlsciphers fields and one fixes the L7 policy redirect fields. - The listener and pool tlsciphers fields were introduced in Octavia 6.0.0. Releases within the affected range that predate 6.0.0 are vulnerable only through the L7 policy redirecturl and redirectprefix fields. - These issues were originally triaged as a low-severity hardening opportunity and the fixes were developed and merged in public. They were reclassified after a proof of concept demonstrated remote code execution as root on the amphora and reachability of the control-plane network. - The remote code execution issue was reported to the OpenStack VMT by Thomas Goirand (zigo) of Infomaniak, on behalf of the reporter, "Rolix". - CVE identifiers were requested from MITRE for these two vulnerabilities on 2026-09-17. The CVEs will be added to this advisory by errata once assigned.

-- Goutham Pacha Ravi OpenStack Vulnerability Management Team https://security.openstack.org/vmt.html

Authenticated Elektra users were able to execute arbitrary code and potentially access otherwise unreachable remote systems; attackers could have also triggered code execution by sending crafted links to authenticated users.

An SSRF issue was discovered in OpenStack Glance before Newton. The 'copyfrom' feature in the Image Service API v1 allowed an attacker to perform masked network port scans. With v1, it is possible to create images with a URL such as 'http://localhost:22'. This could then allow an attacker to enumerate internal network details while appearing masked, since the scan would appear to originate from the Glance Image service.

An issue was discovered in OpenStack Nova before 30.2.2, 31 before 31.2.1, and 32 before 32.1.1. By writing a malicious QCOW header to a root or ephemeral disk and then triggering a resize, a user may convince Nova's Flat image backend to call qemu-img without a format restriction, resulting in an unsafe image resize operation that could destroy data on the host system. Only compute nodes using the Flat image backend (usually configured with usecowimages=False) are affected.

An issue was discovered in OpenStack Horizon 25.6 and 25.7 before 25.7.3. There is a write operation to the session storage backend before authentication and thus storage can be exhausted by unauthenticated requests. This is a regression of the CVE-2014-8124 fix.

Unconstrained disk format handling vulnerability in OpenStack Nova when invoking the qemu-img utility. The flaw occurs because Nova does not strictly enforce the expected disk image format before calling qemu-img. An authenticated attacker can write a crafted QCOW2 header to a raw ephemeral or root disk. When Nova later performs operations such as instance resize, qemu-img interprets the disk as QCOW2 and overwrites arbitrary files on the compute host that Nova has write access to. This can be exploited without additional privileges or user interaction, allowing attackers to destroy other users’ data, corrupt Nova-managed files, or cause denial of service on the compute node.

In 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.

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.

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 projectid, container name, and object name are known. This affects all deployments using the default s3acl=false configuration.

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 s3acl=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 projectid, container name, and object name are known, regardless of the source object's ACLs or ownership. This requires the non-default s3acl=true configuration.

In 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.

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 handlenotify 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.

In OpenStack Designate before 22.0.1, zone creation checks (issubzone, issuperzone, 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 schedulerfilters, which is a non-default but documented and supported configuration for self-service tiering.

Last updated 19 August 2026

In OpenStack Aodh before 22.0.1, the alarm list API bypasses project scoping when the allprojects query parameter is set to false. The API checks for the presence of the allprojects 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 projectid 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).