CVE-2026-97147: OpenStack Mistral Auth Bypass Vulnerability

CVE-2026-97147 Overview

CVE-2026-97147 is an authorization flaw in OpenStack Mistral through version 23.0.0. Several v2 API write paths resolve target objects using queries that can return resources belonging to a different project, then write to them. An authenticated project member can rewrite and un-publish another project's public action definitions and environments. A project administrator can create a workbook whose embedded ad-hoc action or workflow name collides with another project's resource, moving that resource into the caller's project. The original owner's subsequent updates then fail with server errors. Only deployments exposing the Mistral API are affected. The flaw is tracked as CWE-863: Incorrect Authorization.

Critical Impact

Authenticated tenants can modify, un-publish, or hijack workflow resources belonging to other OpenStack projects, breaking tenant isolation in multi-tenant clouds.

Affected Products

• OpenStack Mistral through 23.0.0
• Any OpenStack deployment exposing the Mistral v2 API
• Multi-tenant OpenStack clouds with shared Mistral workflow services

Discovery Timeline

• 2026-10-08 - CVE-2026-97147 published to the National Vulnerability Database (NVD)
• 2026-10-14 - Last updated in NVD database

Technical Details for CVE-2026-97147

Vulnerability Analysis

Mistral is the OpenStack workflow-as-a-service component. Resources such as action definitions, workflows, workbooks, and environments are scoped to a project_id to enforce tenant isolation. The v2 API write paths violate this model.

When handling update, delete, and publish operations, the affected endpoints resolve the target resource by name or identifier without consistently constraining the lookup to the caller's project. The database query can match a resource owned by another tenant, and the subsequent write proceeds against that record.

Two exploitation outcomes are documented. First, an authenticated project member can overwrite another project's public action definitions and environments, including un-publishing them. Second, a project administrator can submit a workbook containing an ad-hoc action or workflow whose name collides with another project's resource. The ownership of the collided resource is reassigned to the caller's project, and the original owner's later updates fail with server errors.

Root Cause

The root cause is missing authorization scoping in Mistral v2 API write handlers. Lookups rely on resource name uniqueness assumptions that do not hold across project boundaries. Writes are permitted without re-validating that the resolved object's project_id matches the authenticated context, satisfying the [CWE-863] pattern.

Attack Vector

Exploitation requires network access to the Mistral API and valid credentials for any project in the OpenStack deployment. No user interaction is required. The attacker invokes a vulnerable v2 write endpoint (for example, workbook creation or action update) referencing a resource name used by a victim project. The server resolves and writes to the victim's resource or reassigns it to the attacker's project.

See the OpenStack Security Advisory OSSA-2026-044 and the Launchpad Mistral Bug Report for the authoritative technical description.

Detection Methods for CVE-2026-97147

Indicators of Compromise

• Unexpected changes to project_id ownership on Mistral action definitions, workflows, workbooks, or environments.
• Mistral API error logs showing update or delete failures by the legitimate resource owner after a cross-tenant collision.
• Workbook create or action create requests from one project whose embedded names match resource names in other projects.
• Public actions or environments becoming unexpectedly un-published or modified without an administrative change ticket.

Detection Strategies

• Audit the Mistral database for resources whose project_id changed outside of expected administrative operations.
• Correlate Keystone authentication tokens with Mistral API write operations to identify cross-tenant naming patterns.
• Enable Mistral API access logging and alert on PUT, POST, and DELETE operations against resource names that exist in more than one project.

Monitoring Recommendations

• Forward Mistral API logs and OpenStack audit middleware events to a centralized SIEM for cross-tenant anomaly analysis.
• Baseline per-project workflow and action inventories, then alert on sudden ownership transfers or publication state changes.
• Monitor server-side 500-class errors on Mistral update endpoints, which indicate the collision-driven failure mode described in the advisory.

How to Mitigate CVE-2026-97147

Immediate Actions Required

• Restrict network exposure of the Mistral API to trusted administrative networks until a patched release is deployed.
• Review all Mistral action definitions, workflows, workbooks, and environments for unexpected project_id reassignments or content changes.
• Rotate credentials for any tenant suspected of abusing the v2 API write paths.
• Apply updates referenced in OSSA-2026-044 as soon as fixed packages are available for your distribution.

Patch Information

Refer to OpenStack Security Advisory OSSA-2026-044 and the upstream fix tracked in Launchpad bug 2160267 for the list of patched Mistral versions and backports. Deployers using distribution packages should install the vendor-supplied update that incorporates the upstream commit for this issue.

Workarounds

• Limit Mistral API access to a reduced set of trusted projects using Keystone policy and network ACLs.
• Enforce stricter policy.json or policy.yaml rules on Mistral v2 write endpoints to require project-scoped tokens with elevated roles.
• Avoid using Mistral in multi-tenant deployments where mutual trust between projects cannot be assumed, pending patch application.
• Rename public action definitions and environments to project-prefixed identifiers to reduce the probability of name collisions.