Mistral
Monthly
Cross-project resource manipulation in OpenStack Mistral through 23.0.0 allows an authenticated project member to rewrite and un-publish another project's public action definitions and environments via the v2 API, while a project administrator can relocate another project's resource by creating a workbook with a colliding embedded action or workflow name. This incorrect authorization vulnerability (CWE-863) has a CVSS 4.0 base score of 7.2 (High) and requires a valid account on a multi-tenant cloud that exposes the Mistral v2 API; no public exploit code was identified at time of analysis, and the impact is primarily integrity (VI:H) with limited confidentiality and availability effects. Deployments without the Mistral API exposed are not affected.
Cluster-wide denial of service in OpenStack Mistral (all versions through 23.0.0) lets any authenticated holder of a valid Mistral token - regardless of role or tenant - read and alter the service's global maintenance state through the /v2/maintenance API, because the controller clears the request context and calls the maintenance service without any policy enforcement. Setting the state to PAUSED halts processing of new workflow and execution objects for every tenant project until an operator intervenes, giving a lowest-privileged tenant member a persistent, cross-tenant availability impact (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H, 7.1 High; NVD's CVSS 4.0 vector scores identically at 7.1 High). Exploit path is reachable against default configurations with no feature flag or non-default setting required, but it is not anonymously exploitable - a valid Mistral API token is the single prerequisite. No confirmed active exploitation (not in CISA KEV) and no public exploit code has been identified at time of analysis; patch availability is not confirmed in the provided data.
OpenStack Mistral through 23.0.0 exposes an authenticated command-injection path in its std.ssh_proxied action: the caller-supplied proxy_command string is handed to paramiko.ProxyCommand() and executed as a local subprocess on the executor host under the Mistral service account, before any SSH connection to the gateway or target host is even attempted. Any authenticated project member who can reach the standard action-execution API can therefore run arbitrary OS commands on the Mistral executor, with the default configuration affected because std.ssh_proxied is permitted out of the box; deployments that explicitly disable or restrict that action are not impacted. Exploitation requires valid project credentials (PR:L, not anonymous), so the practical risk is privilege escalation and lateral movement from a low-privileged tenant account rather than unauthenticated compromise, and no public exploit code was identified at time of analysis.
An authenticated tenant (PR:L) can abuse OpenStack Mistral's workflow membership API to grant a third project read and execution access to another project's private workflow without the owner's consent. Exploitation requires an existing, already-accepted share of the target workflow plus a third project under the attacker's control or collusion to accept the forged membership, which causes the new membership row to be written with the accepting project's ID instead of the original owner's - leaving the owner unable to see or revoke it. The result is a multi-tenant authorization bypass (CWE-863) confined to confidentiality and execution of the specifically shared workflow; no public exploit code has been identified at time of analysis. Per the independent assessment this is a genuine but moderate-priority flaw, not a high-severity issue, and it only affects multi-tenant deployments that actively use Mistral workflow sharing.
Cross-project resource manipulation in OpenStack Mistral through 23.0.0 allows an authenticated project member to rewrite and un-publish another project's public action definitions and environments via the v2 API, while a project administrator can relocate another project's resource by creating a workbook with a colliding embedded action or workflow name. This incorrect authorization vulnerability (CWE-863) has a CVSS 4.0 base score of 7.2 (High) and requires a valid account on a multi-tenant cloud that exposes the Mistral v2 API; no public exploit code was identified at time of analysis, and the impact is primarily integrity (VI:H) with limited confidentiality and availability effects. Deployments without the Mistral API exposed are not affected.
Cluster-wide denial of service in OpenStack Mistral (all versions through 23.0.0) lets any authenticated holder of a valid Mistral token - regardless of role or tenant - read and alter the service's global maintenance state through the /v2/maintenance API, because the controller clears the request context and calls the maintenance service without any policy enforcement. Setting the state to PAUSED halts processing of new workflow and execution objects for every tenant project until an operator intervenes, giving a lowest-privileged tenant member a persistent, cross-tenant availability impact (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H, 7.1 High; NVD's CVSS 4.0 vector scores identically at 7.1 High). Exploit path is reachable against default configurations with no feature flag or non-default setting required, but it is not anonymously exploitable - a valid Mistral API token is the single prerequisite. No confirmed active exploitation (not in CISA KEV) and no public exploit code has been identified at time of analysis; patch availability is not confirmed in the provided data.
OpenStack Mistral through 23.0.0 exposes an authenticated command-injection path in its std.ssh_proxied action: the caller-supplied proxy_command string is handed to paramiko.ProxyCommand() and executed as a local subprocess on the executor host under the Mistral service account, before any SSH connection to the gateway or target host is even attempted. Any authenticated project member who can reach the standard action-execution API can therefore run arbitrary OS commands on the Mistral executor, with the default configuration affected because std.ssh_proxied is permitted out of the box; deployments that explicitly disable or restrict that action are not impacted. Exploitation requires valid project credentials (PR:L, not anonymous), so the practical risk is privilege escalation and lateral movement from a low-privileged tenant account rather than unauthenticated compromise, and no public exploit code was identified at time of analysis.
An authenticated tenant (PR:L) can abuse OpenStack Mistral's workflow membership API to grant a third project read and execution access to another project's private workflow without the owner's consent. Exploitation requires an existing, already-accepted share of the target workflow plus a third project under the attacker's control or collusion to accept the forged membership, which causes the new membership row to be written with the accepting project's ID instead of the original owner's - leaving the owner unable to see or revoke it. The result is a multi-tenant authorization bypass (CWE-863) confined to confidentiality and execution of the specifically shared workflow; no public exploit code has been identified at time of analysis. Per the independent assessment this is a genuine but moderate-priority flaw, not a high-severity issue, and it only affects multi-tenant deployments that actively use Mistral workflow sharing.