CVE-2026-107363 in Zaqar
Summary
by MITRE • 10/07/2026
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. 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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/07/2026
The vulnerability identified in OpenStack Zaqar prior to version 23.0.1 represents a critical authorization failure within the message queuing service's WebSocket transport layer. This flaw stems from an insufficient validation of project identifiers during subsequent requests that follow initial authentication via Keystone tokens. While the system correctly authenticates the user and associates them with their primary authenticated project, it fails to enforce this association when processing messages or commands sent over persistent WebSocket connections. Consequently, the application trusts client-supplied project UUIDs in these ongoing sessions without verifying that they match the project context established during the initial authentication handshake. This architectural oversight allows an attacker who has obtained a valid Keystone token for one specific project to manipulate requests targeting different projects within the same OpenStack deployment.
From a technical perspective, this issue is classified as CWE-269 Improper Privilege Management and specifically aligns with CWE-862 Missing Authorization. The root cause lies in the stateful nature of WebSocket connections where session context must be strictly maintained and validated against every incoming action. In standard HTTP-based interactions, each request typically carries its own authentication headers or tokens that are re-evaluated by the server middleware. However, WebSocket transports often rely on a persistent connection established after an initial handshake. If the backend logic does not explicitly bind the project identifier from the authenticated session to all subsequent operations within that socket, it creates a blind spot for access control enforcement. An attacker can exploit this by crafting malicious messages or API calls over the open WebSocket channel and injecting UUIDs belonging to other tenants or projects.
The operational impact of this vulnerability is severe, as Zaqar serves as a core component for inter-service communication in many OpenStack architectures. Successful exploitation allows an authenticated user with access to one project to perform unauthorized enumeration, inspection, creation, and deletion of queues associated with entirely different projects. This leads to the unauthorized disclosure of sensitive data stored within those queues, potential modification or destruction of critical workflow messages, and a complete breakdown of multi-tenancy isolation. In cloud environments where Zaqar facilitates communication between services like Nova, Neutron, or Cinder, such an attack could disrupt service operations, cause denial of service through queue flooding or deletion, or lead to data leakage across tenant boundaries. The risk is particularly acute in deployments that rely heavily on the WebSocket transport mechanism for real-time messaging and have not implemented additional compensating controls at the network or proxy level.
This vulnerability maps directly to MITRE ATT&CK technique T1078 Valid Accounts, as it requires initial authentication but then escalates privileges by bypassing authorization checks. It also relates to T1534 Internal Spearphishing if used in conjunction with social engineering to gain initial access, though the core exploit is purely technical. The attack vector involves interacting directly with the Zaqar API over WebSocket connections, which may be exposed through load balancers or reverse proxies configured for long-lived connections.
Mitigation strategies must prioritize upgrading OpenStack Zaqar to version 23.0.1 or later, where this binding logic has been corrected to ensure that project identifiers are consistently validated against the authenticated session context. For environments unable to upgrade immediately, administrators should consider disabling the WebSocket transport if it is not strictly required for their use case, thereby removing the attack surface entirely. Additionally, implementing strict network segmentation and firewall rules can limit exposure of Zaqar endpoints to only trusted internal services or specific client IP ranges. Monitoring logs for unusual patterns in queue access across different project IDs may also help detect exploitation attempts before significant damage occurs. Regular security audits focusing on authorization logic in stateful protocol implementations are recommended to prevent similar flaws in other components of the cloud infrastructure.