CVE-2026-108111 in ruoyi-ai
Summary
by MITRE • 10/09/2026
ruoyi-ai 3.0.0 through 3.1.0 contains a missing authorization vulnerability in the GET /workflow/search endpoint that exposes other users' private workflows. Authenticated non-admin users can query this endpoint, which lacks owner or is_public filtering, to list enabled private workflows in the same tenant, including UUIDs and full node and edge configurations.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/09/2026
The vulnerability identified in RuoYi-AI versions 3.0.0 through 3.1.0 represents a critical failure in access control mechanisms within the workflow management module. Specifically, the GET /workflow/search endpoint is designed to allow users to search for workflows, but it fails to implement proper authorization checks regarding resource ownership or visibility status. In a multi-tenant SaaS architecture like RuoYi-AI, data isolation between tenants and strict role-based access control within each tenant are fundamental security requirements. The absence of these controls allows authenticated non-administrative users to bypass intended privacy restrictions and access sensitive operational data belonging to other users within the same organization or tenant context.
From a technical perspective, the flaw lies in the backend logic handling the search request for workflows. When an authenticated user submits a query via this endpoint, the application retrieves workflow records based on criteria such as status (e.g., enabled) but neglects to filter results by the owner_id field or check if the is_public flag is set to true. Consequently, any valid session token associated with a non-administrative account can be used to enumerate all active workflows in that tenant's scope. The response payload includes not only basic metadata like workflow UUIDs and names but also detailed structural information including full node configurations and edge connections. This level of detail effectively provides the complete blueprint for how each workflow operates, including decision logic, service integrations, and data flow paths.
The operational impact of this vulnerability is severe due to the richness of the exposed data. An attacker can map out the internal business processes of an organization by analyzing the structure of these private workflows. This intelligence gathering phase facilitates further attacks such as privilege escalation or targeted exploitation of downstream services referenced in the workflow nodes. For instance, if a workflow contains steps that invoke specific API endpoints with hardcoded credentials or rely on trusted service accounts, understanding this configuration allows an attacker to craft precise requests against those external systems. Additionally, exposure of UUIDs and internal identifiers can aid in subsequent injection attacks or logic flaws exploitation where unique identifiers are used for state management or resource resolution without proper validation.
This vulnerability aligns directly with CWE-285, which describes Improper Authorization, specifically the failure to enforce access controls on resources based on user roles or ownership attributes. It also maps to MITRE ATT&CK technique T1078, Valid Accounts, as it requires initial authentication but exploits weak session management and authorization logic rather than credential theft. Furthermore, the enumeration of internal structures relates to reconnaissance activities often categorized under information gathering techniques where attackers seek to understand system architecture for future exploitation vectors.
Mitigation strategies must focus on implementing robust server-side access control checks within the workflow search service layer. Developers should ensure that every query for sensitive resources includes mandatory filters for tenant_id and owner_id, ensuring users only retrieve data they explicitly own or have been granted permission to view. The is_public flag should be treated as a strict gatekeeper; if it is false, the record must never appear in results unless the requester matches the owner identity verified against their session context. Additionally, implementing principle of least privilege for API endpoints and conducting regular code reviews focused on authorization logic can prevent similar oversights. Input validation alone is insufficient here since the issue stems from business logic rather than malformed input; therefore, explicit ownership verification before data serialization into the response object is essential to restore security posture.