CVE-2026-76878: Openstack Aodh vulnerability
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).
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
OpenStack Aodhto a version that resolves this vulnerability.Fixed in 22.0.1 - Configuration
Fix the alarm list API so authorization/project scoping is enforced based on the actual value of the all_projects parameter; do not bypass project scoping when all_projects=false, and prevent combining all_projects with a foreign project_id to target other projects.
OpenStack Aodh alarm list API all_projects query parameter handling = Require correct all_projects value (do not branch based on presence of key) - Configuration
Apply policy checks to the Watcher webhook trigger endpoint introduced in the Ussuri release (Watcher 4.0.0) so that authenticated users cannot start EVENT audits/action plans for audits not in their own project or allowed role.
OpenStack Watcher webhook trigger endpoint Authorization enforcement = Enforce project/role policy on webhook endpoint
Event History
Frequently Asked Questions
Who can access alarms outside their own project?
A non-administrative user with the reader role can list alarms from all projects by setting the all_projects query parameter to false. The request can also include another project's project_id to focus on that project's alarms.
What information may be exposed through the alarm listing issue?
Exposed alarm actions can contain trust webhook URLs, Heat signal endpoints, project IDs, and user IDs. A leaked Watcher audit webhook URL may enable a separate unauthorized trigger action.
What is required to trigger a Watcher audit through a webhook URL?
The requester must be authenticated and know the audit's webhook URL. Watcher does not enforce project- or role-based authorization on this endpoint, so such a user can start an EVENT audit and its associated action plan regardless of their project or role.
Which deployments are identified as affected?
The Aodh issue affects versions before 22.0.1. The Watcher webhook authorization concern has existed since its introduction in the Ussuri release, Watcher 4.0.0.