OpenStack Mistral Critical SSH Proxy Flaw Enables Remote Code Execution for Authenticated Users

The short version

• An authenticated user can execute arbitrary local commands on the Mistral executor host.
• The attack vector uses the standard action-execution API to inject a malicious proxy command.
• The command runs under the service account regardless of whether the SSH connection succeeds.

The details

OpenStack Mistral contains a command injection vulnerability that allows an attacker to execute arbitrary code on the server hosting the executor service. According to the National Vulnerability Database, the issue is tracked as CVE-2026-93858 and carries a CVSS score of 8.7, categorized as High severity. The flaw stems from how the `std.ssh_proxied` action handles user input.

When this action is invoked, it passes a caller-supplied `proxy_command` value directly to the `paramiko.ProxyCommand()` function. This occurs before any attempt is made to establish an SSH connection to a gateway or target host. Because the input is not sanitized, an authenticated project member can submit an arbitrary local command via the standard action-execution API. The `paramiko` library then starts this command as a subprocess on the executor host. Crucially, this execution happens under the executor's own service account, independent of the success or failure of the intended SSH connection.

The vulnerability affects deployments that permit the `std.ssh_proxied` action. According to the advisory, this is the default configuration for Mistral. As a result, most standard installations are exposed unless administrators have explicitly disabled this specific action.

The context

The issue was detailed in advisory OSSA-2026-044, posted by Jeremy Stanley on the oss-security mailing list on October 8, 2026. The advisory groups this command injection with three other authorization and privilege vulnerabilities in Mistral: CVE-2026-93860, CVE-2026-93861, and CVE-2026-97147.

The affected software versions are those prior to 20.1.1, prior to 21.0.1, prior to 22.0.1, and version 23.0.0. The weakness is classified under CWE-78, which refers to Improper Neutralization of Special Elements used in an OS Command. For business leaders, the risk is significant because the attacker gains command execution on the infrastructure layer (the executor host) rather than just the target environment. This could allow lateral movement or data exfiltration from the management plane.

What to watch

Organizations should verify if they are using the default Mistral configuration, which includes the vulnerable `std.ssh_proxied` action. Security teams should monitor API logs for unusual `proxy_command` values or subprocess spawns on executor nodes that do not correspond to legitimate SSH tunneling activity. Since the exploit requires an authenticated project member, insider threats or compromised low-privilege accounts are the primary vectors.

What to do and how to stay safe: OpenStack

• Audit your Mistral deployment to determine if the `std.ssh_proxied` action is enabled, as this is the default setting.
• If the action is not strictly required for your workflows, consider disabling it to eliminate the attack surface immediately.
• Review API access logs for authenticated users submitting actions with complex or unexpected command strings in the proxy field.
• Once the vendor provides an update, apply the patch to versions 20.1.1, 21.0.1, 22.0.1, or newer to resolve the injection flaw.

Step-by-step guide: Automatic Software Updates: Definition, Mechanics and Hidden Risks

General security guidance from the TechSec Headlines newsroom. It is not confirmed advice from the organisations named in this story.

Frequently asked questions

Does this vulnerability require the SSH connection to succeed?

No, the arbitrary command executes as a subprocess on the executor host regardless of whether the SSH connection to the target succeeds.

Which versions of OpenStack Mistral are affected?

Versions before 20.1.1, before 21.0.1, before 22.0.1, and 23.0.0 are affected.

Is authentication required to exploit this bug?

Yes, an authenticated project member must use the standard action-execution API to submit the malicious command.