CVE-2026-76878 in Aodh
Summary
by MITRE • 08/20/2026
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).
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/20/2026
The vulnerability identified in OpenStack Aodh prior to version 22.0.1 represents a critical authorization bypass stemming from flawed logic within the alarm list API implementation. The core technical flaw lies in how the application evaluates the all_projects query parameter during access control checks. Instead of verifying that the value of this parameter is explicitly set to true, the code merely checks for the presence of the key itself. When an authenticated user sets the parameter to false, the system removes the key from the request context and subsequently skips the branch of logic designed to restrict results to only those alarms belonging to the caller's specific project. This logical error effectively neutralizes the intended scoping mechanism, allowing any non-administrator user with a reader role to retrieve alarm data across all projects within the cloud environment rather than being limited to their own scope as originally intended by the security policy design.
The operational impact of this flaw is severe due to the sensitive nature of the data exposed through the compromised API endpoint. By bypassing project scoping, attackers can enumerate alarms from every tenant in the infrastructure, thereby gaining access to alarm actions that contain trust webhook URLs and Heat signal endpoints. These components are critical for orchestration and automation workflows within OpenStack environments. The exposure includes not only internal service identifiers but also specific project IDs and user IDs associated with various tenants. This level of information disclosure facilitates further reconnaissance efforts, allowing an attacker to map out the infrastructure topology, identify active services, and pinpoint high-value targets for subsequent exploitation attempts based on the discovered metadata.
Compounding this issue is a related authorization failure within OpenStack Watcher, which lacks proper policy enforcement on its webhook trigger endpoint since its introduction in the Ussuri release (Watcher 4.0.0). This secondary vulnerability creates a dangerous chain of exploitation when combined with the Aodh flaw. Once an attacker obtains audit webhook URLs through the leaked alarm metadata from Aodh, they can directly interact with Watcher’s API without any additional authentication checks tied to their own project or role permissions. By sending requests to these exposed endpoints, authenticated users who should have no authority over specific audits are able to initiate EVENT audits and trigger associated action plans across foreign projects. This effectively allows lateral movement within the cloud environment, enabling unauthorized control over security monitoring systems and automated remediation actions intended for other tenants.
From a classification perspective, this vulnerability aligns with CWE-284 Improper Access Control, specifically reflecting failures in enforcing scope-based restrictions on API endpoints. The ability of an authenticated user to access resources belonging to other users or projects constitutes a direct violation of isolation principles fundamental to multi-cloud architectures. Furthermore, the exploitation path involving the use of discovered webhook URLs to trigger unauthorized actions maps closely to ATT&CK techniques related to Command and Control via remote services as well as Defense Evasion through manipulation of security monitoring tools. The combination of information disclosure leading to privilege escalation across service boundaries highlights a systemic gap in how OpenStack components validate user permissions against resource ownership during API interactions.
To mitigate these risks, organizations running affected versions must immediately upgrade OpenStack Aodh to version 22.0.1 or later where the logic for handling the all_projects parameter has been corrected to properly evaluate its boolean value rather than just its presence. Additionally, administrators should apply patches addressing the Watcher webhook endpoint authorization issues as soon as they become available in subsequent releases. In environments where immediate patching is not feasible, network-level controls such as firewall rules restricting access to Aodh and Watcher API endpoints can provide a temporary layer of defense by limiting exposure to trusted internal subnets only. Regular auditing of IAM policies and review of webhook configurations are also recommended to ensure that no unintended cross-project permissions exist within the deployment architecture.