CVE-2026-97404 in Zaqar
Summary
by MITRE • 09/24/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/24/2026
The vulnerability identified in OpenStack Zaqar prior to version 22.0.2 represents a critical failure in access control mechanisms within the Web Server Gateway Interface transport layer. This flaw specifically impacts systems that utilize WSGI for handling incoming requests and have an authentication strategy configured, such as Keystone integration. The core technical issue stems from improper validation of the URL-Signature header during request processing. When an attacker sends a request containing an empty value for this header, the application fails to properly enforce cryptographic verification or signature checks that are intended to validate the authenticity and integrity of the request. This logic error allows the system to treat the malformed request as valid, effectively bypassing both the standard Keystone authentication process and any pre-signed URL verification mechanisms designed to restrict access based on time-limited tokens or specific permissions.
From a technical perspective, this flaw is classified under CWE-287, which denotes Improper Authentication, and aligns with MITRE ATT&CK technique T1078, Valid Accounts, as it allows an unauthenticated actor to assume the privileges of a legitimate user without providing valid credentials. The attacker requires knowledge of the target project's UUID, which is often exposed through API endpoints or enumeration techniques if other access controls are not strictly enforced. Once this identifier is obtained, the exploitation path involves sending HTTP requests with an empty URL-Signature header directed at Zaqar endpoints associated with that specific project ID. Because the WSGI transport mishandles this input, it skips the necessary security checks and grants the attacker full operational control over the targeted resources.
The operational impact of this vulnerability is severe due to the breadth of actions available to an exploited account. An unauthenticated remote attacker can read sensitive data stored in queues, enumerate existing messages, create new entries that could be used for further attacks or resource exhaustion, delete critical information leading to denial of service or data loss, and manage subscriptions which may facilitate phishing or social engineering campaigns against other users within the project. In deployments where administrative roles are accessible through this mechanism, such as those running in admin_mode with pools and flavors managed by Zaqar, the attacker can escalate privileges significantly. This allows for the manipulation of infrastructure components like message broker pools and flavor configurations, potentially leading to broader compromise of the cloud environment's stability or security posture.
Mitigation strategies must prioritize immediate patching to version 22.0.2 or later, where this input validation logic has been corrected to reject empty signatures appropriately. For environments that cannot be patched immediately, network-level controls should be implemented to restrict access to Zaqar endpoints only from trusted internal networks if possible. Additionally, security teams should audit logs for unusual patterns of requests containing empty signature headers targeting project UUIDs known within the organization. It is also crucial to verify that authentication strategies are robustly configured and that least-privilege principles are enforced across all projects to limit the blast radius in case of future vulnerabilities. The websocket transport remains unaffected by this specific flaw, but organizations should ensure consistent security configurations across all supported transports to maintain a uniform defense posture.