CVE-2026-22683
Authorization Bypass in Windmill Operator Role Enables RCE
Publication date: 2026-04-07
Last updated on: 2026-04-24
Assigner: VulnCheck
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| nextcloud | flow | From 1.0.0 (inc) to 1.2.2 (inc) |
| windmill | windmill | From 1.56.0 (inc) to 1.614.0 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-862 | The product does not perform an authorization check when an actor attempts to access a resource or perform an action. |
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability in Windmill allows users with the Operator role to perform unauthorized creation and modification of critical entities, leading to privilege escalation and potential remote code execution. This unauthorized access and modification capability can lead to violations of data protection and security requirements mandated by standards such as GDPR and HIPAA, which require strict access controls and prevention of unauthorized data manipulation.
By allowing Operators to bypass intended restrictions, the vulnerability increases the risk of unauthorized data access or alteration, which could result in non-compliance with regulations that mandate role-based access control, auditability, and data integrity.
The fix implemented restricts Operator permissions to prevent these unauthorized actions, thereby helping to restore compliance with such standards by enforcing proper authorization checks.
Can you explain this vulnerability to me?
This vulnerability exists in Windmill versions 1.56.0 through 1.614.0 and involves a missing authorization check in the backend API. Users assigned the Operator role, who are not supposed to create or modify entities, can bypass these restrictions and perform prohibited actions such as creating and updating scripts, flows, apps, and raw_apps. Because Operators can also execute scripts, this flaw allows them to escalate their privileges to remote code execution within the Windmill deployment.
How can this vulnerability impact me? :
The vulnerability allows users with the Operator role to perform unauthorized creation and modification of critical entities, which they are not supposed to do. This can lead to privilege escalation, enabling Operators to execute arbitrary code remotely within the Windmill environment. Such unauthorized actions can compromise the integrity, confidentiality, and availability of the system, potentially leading to data breaches, service disruption, or further exploitation.
What immediate steps should I take to mitigate this vulnerability?
To mitigate CVE-2026-22683, you should upgrade Windmill to version 1.615.0 or later, where operator permissions have been tightened to prevent unauthorized creation and modification of apps, flows, raw apps, and scripts.
The fix involves explicit authorization checks in the backend API that block users with the Operator role from performing write operations on critical resources, thereby preventing privilege escalation and remote code execution.
- Upgrade Windmill to version 1.615.0 or newer.
- Ensure that operator roles cannot create or update apps, flows, raw apps, or scripts by verifying backend API permissions.
- Review and apply any additional security patches related to operator role restrictions.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability involves unauthorized creation and modification of entities by users with the Operator role via the backend API in Windmill versions 1.56.0 through 1.614.0. Detection would involve monitoring API requests to workspace endpoints for unauthorized create or update actions performed by Operator role users.
Specifically, you can look for API calls that create or update apps, flows, raw apps, or scripts initiated by Operator users, which should normally be disallowed.
Suggested commands or methods to detect this include:
- Review API access logs for requests to endpoints related to apps, flows, raw apps, and scripts creation or updates.
- Filter logs for requests authenticated as users with the Operator role.
- Look for HTTP methods POST or PUT/PATCH on these endpoints indicating creation or modification.
- Example command to search logs (assuming logs contain role and endpoint info):
- grep -i 'operator' /path/to/api_access.log | grep -E 'POST|PUT|PATCH' | grep -E '/apps|/flows|/raw_apps|/scripts'
Additionally, monitoring for error messages or authorization failures related to operator actions might help identify attempts to exploit this vulnerability.