CVE-2026-54136 in Windmill
Summary
by MITRE • 08/20/2026
Windmill is an open-source developer platform for internal code: APIs, background jobs, workflows and UIs. Prior to 1.715.0, a resource-scoped API token could read script contents outside its allowed path scope through GET /api/w/{workspace}/scripts/list_search. The route-level scope middleware validated the token domain and action but did not enforce the resource/path segment, and the list_search_scripts handler had no additional check_scopes call or per-row filtering before returning script path and content fields. A token such as scripts:read:f/allowed/* could therefore receive source code for unrelated paths in the same workspace, potentially disclosing internal automation logic, integration details, business logic, inline configuration, or hardcoded secrets and credentials. Exploitation required possession of a valid scoped API token for the workspace but did not require administrator privileges. This issue is fixed in version 1.715.0.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/20/2026
The vulnerability identified in Windmill prior to version 1.715.0 represents a critical authorization bypass within its internal developer platform, specifically affecting resource-scoped API tokens used for accessing scripts and automation logic. As an open-source platform designed to host APIs, background jobs, workflows, and user interfaces, the security of script contents is paramount because these assets often contain sensitive business logic, integration details, and hardcoded credentials. The flaw resides in the middleware layer responsible for validating token scopes against specific resource paths during requests to the GET /api/w/{workspace}/scripts/list_search endpoint. While the route-level scope middleware correctly validated the general domain and action associated with a given API token, it failed to enforce strict adherence to the resource or path segment constraints defined by the token's permissions. This architectural oversight allowed tokens scoped to specific directories to traverse beyond their intended boundaries.
Technically, the issue stems from an incomplete implementation of access control checks within the list_search_scripts handler. When processing a request for script listings and content, the application did not invoke additional scope verification functions or apply per-row filtering mechanisms before returning results. Consequently, if an attacker possessed a valid API token with read permissions scoped to a specific path pattern, such as scripts:read:f/allowed/*, they could exploit this gap to retrieve source code from unrelated paths within the same workspace. The absence of granular validation at the data retrieval stage meant that the server returned script metadata and content fields without verifying whether each individual result fell within the authorized scope of the requesting token. This lack of row-level security is a classic example of broken access control where coarse-grained permissions are applied but fine-grained enforcement is missing during data serialization and response generation.
The operational impact of this vulnerability is severe, as it facilitates unauthorized disclosure of sensitive internal information. By accessing scripts outside their allowed path scope, an attacker could expose the underlying automation logic that powers critical business processes, revealing integration points with external systems or databases. More critically, since these scripts often contain inline configuration data and hardcoded secrets such as API keys, database passwords, or cloud provider credentials, the vulnerability effectively serves as a credential harvesting vector. The exploitation does not require administrative privileges; possession of any valid scoped API token for the workspace is sufficient to trigger the information leak. This lowers the barrier to entry significantly, allowing lower-privileged users or compromised service accounts to escalate their impact by extracting sensitive intellectual property and authentication material from other parts of the application infrastructure.
From a classification perspective, this vulnerability aligns with CWE-269 Improper Privilege Management due to the failure to enforce resource-specific restrictions on an authorized user account. It also maps directly to MITRE ATT&CK technique T1530 Data from Cloud Storage Object or T1537 Transfer Data to Cloud Account depending on how the exfiltrated data is utilized, but more accurately reflects CWE-862 Missing Authorization in the context of API endpoints where access control checks are incomplete. The vulnerability highlights a common pitfall in web application development where developers assume that middleware-level scope validation provides sufficient protection without implementing additional safeguards at the handler level to ensure data integrity and confidentiality during retrieval operations.
To mitigate this risk, organizations running Windmill must upgrade immediately to version 1.715.0 or later, which addresses the flaw by enforcing strict resource-path segment validation within the script listing handlers. For environments where an immediate upgrade is not feasible, temporary mitigations should focus on restricting API token scopes to the absolute minimum necessary for functionality and auditing all tokens with broad path wildcards such as * to ensure they are only assigned to users who genuinely require access to those specific resources. Implementing strict least-privilege principles for internal service accounts can significantly reduce the blast radius if a token is compromised, ensuring that even if an attacker obtains a scoped token, its utility in extracting sensitive data from unrelated parts of the workspace remains limited by robust server-side enforcement mechanisms.