OpenStack Mistral vulnerabilities

In OpenStack Mistral through 23.0.0, several v2 API write paths resolve the target object with a query that can return another project's resource, then write to it. An authenticated project member can use this to rewrite and un-publish another project's public action definitions and environments.

In OpenStack Mistral through 23.0.0, the workflow membership API lets a project that has accepted a share of another project's private workflow create a further membership naming a third project. The new membership row is created with its project_id defaulted to the accepting project rather than the original workflow owner, and thus the owner can neither see nor delete it. The third project can accept this membership (that it had not actually been granted by the owner), and then read and execute the owner's private workflow; only the accepting (not the owning) project can later revoke that access.

In OpenStack Mistral through 23.0.0, the /v2/maintenance API controller clears the request context and calls the maintenance service directly without any policy enforcement. Any holder of a valid Mistral token, regardless of assigned role, can read and change the service's cluster-wide maintenance state.

In OpenStack Mistral through 23.0.0, the std.ssh_proxied action passes a caller-supplied proxy_command value directly to paramiko.ProxyCommand() before any SSH connection is attempted. An authenticated project member can use the standard action-execution API to submit an arbitrary local command as proxy_command, which is started as a subprocess on the executor host. Only deployments that permit the std.ssh_proxied action, the default configuration, are affected.

OpenStack Mistral through version 22.0.0 contains a remote code execution vulnerability when the API is exposed. Endpoints allow code execution, which can lead to exfiltration of service credentials.