The vulnerability in OpenStack Aodh allows a non‑admin user with a reader role to bypass the intended project scoping in the alarm list API when the all_projects query parameter is set to false. The implementation incorrectly checks for the presence of the all_projects key rather than evaluating its value, causing the API to skip the authorization branch that limits results to the caller’s project. As a result, the attacker can list alarms from every project and expose sensitive information such as trust webhook URLs, Heat signal endpoints, project IDs, and user IDs. Additionally, the Watcher webhook trigger endpoint lacks policy enforcement, enabling any authenticated user who discovers an audit’s webhook URL—potentially from leaked alarm metadata—to start an EVENT audit and trigger its action plan without regard for project or role. These weaknesses align with CWE‑688 and CWE‑863, reflecting incorrect or incomplete access control checks and insufficient policy enforcement that can lead to unauthorized data exposure and manipulation of critical infrastructure components.

The flaw is present in OpenStack Aodh versions earlier than 22.0.1. Users deploying these releases should consider the impact on all projects associated with their OpenStack deployment, as the affected API path resides in the Aodh service cluster.

The CVSS score of 8.4 indicates high severity, reflecting the breach of confidentiality, integrity, and availability. The EPSS score of 0.00392 (below 1%) indicates a low but non‑zero exploitation probability, and the vulnerability is not listed in CISA KEV, suggesting current exploitation attempts are not widely documented. Attackers can exploit the flaw via an authenticated HTTP request to the alarm list API, setting the all_projects parameter to false and optionally specifying a foreign project_id. Because the API skips scope enforcement, the breach does not require elevated privileges beyond a reader role. The related lack of policy enforcement on the Watcher webhook endpoint further inflates the risk, allowing authenticated users to trigger actions across projects. The combined effect is potential full‑project data exfiltration and unauthorized audit initiations.