CVE-2026-93861 in Mistral
Summary
by MITRE • 10/08/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/08/2026
The vulnerability in OpenStack Mistral through version 23.0.0 represents a critical logic flaw within the workflow sharing mechanism, specifically affecting how membership permissions are propagated and managed across multiple projects. This issue stems from an improper implementation of state management during the creation of secondary memberships when workflows are shared between tenants. In a typical multi-tenant cloud environment, strict isolation is required to ensure that one project cannot access or manipulate resources belonging to another without explicit authorization. However, in this scenario, the API endpoint responsible for creating workflow membership entries fails to correctly inherit or validate the original owner's identity during the creation of subsequent memberships derived from an initial share acceptance.
When a first project accepts a shared private workflow from an owning project, it gains limited permissions to view and execute that specific workflow. The vulnerability arises when this accepting project attempts to create a further membership by sharing the same workflow with a third party. Instead of preserving the original context where the owner remains the definitive administrator of the resource, the system defaults the new membership row's project_id field to the identifier of the accepting project rather than retaining the identity of the original workflow owner. This misattribution creates a disconnect between the actual ownership rights and the recorded metadata in the database layer. Consequently, the legitimate owner loses visibility into this newly created entry because their user ID does not match the stored project_id associated with that membership record.
The operational impact of this flaw is severe, as it effectively allows an unauthorized third party to gain persistent access to private workflows without the knowledge or consent of the original creator. Because the ownership metadata is corrupted by defaulting to the accepting project's identifier, the true owner cannot locate, monitor, or revoke these specific memberships through standard administrative interfaces. This creates a blind spot in the security posture where sensitive data processing logic can be executed by entities that were never explicitly granted permission by the resource owner. The third party can accept this illicitly created membership and subsequently read and execute the workflow code, potentially leading to unauthorized access to proprietary algorithms, exposure of sensitive input data processed within those workflows, or even lateral movement if the workflow interacts with other cloud resources based on elevated privileges assumed during execution.
Furthermore, the revocation mechanism is also compromised by this design flaw. Only the project identified in the membership record—the accepting project—can revoke access to that specific entry. The original owner, who retains intellectual property rights and security responsibility for the workflow, is locked out of managing these rogue memberships. This asymmetry undermines the fundamental principle of least privilege and accountability, as it allows a tenant to permanently embed unauthorized access points into another tenant's resources without any easy remediation path available to the victim. Such behavior aligns with CWE-269, which describes Improper Privilege Management, where users are assigned privileges that allow them to perform actions beyond their intended scope. Additionally, this scenario reflects aspects of ATT&CK technique T1530, Data from Cloud Storage Object Discovery or Access, as it involves unauthorized enumeration and execution of cloud-based resources through manipulated permission structures.
To mitigate this vulnerability, immediate patching to version 23.0.1 or later is required, where the logic for setting project identifiers in workflow membership creation has been corrected to preserve the original owner's context regardless of intermediate sharing actions. Administrators should also audit existing Mistral deployments for anomalous membership entries that do not correspond to known authorized shares. Implementing stricter validation checks at the API level to ensure that any derived memberships retain a reference to the root resource owner can prevent similar logic flaws in future iterations. Regular security reviews focusing on multi-tenant isolation boundaries and permission inheritance chains are essential to maintaining robust cloud infrastructure integrity against such logical bypasses.