CVE-2026-22683: Windmill Privilege Escalation Vulnerability

CVE-2026-22683 Overview

CVE-2026-22683 is a missing authorization vulnerability (CWE-862) affecting Windmill versions 1.56.0 through 1.614.0. This vulnerability allows users with the Operator role to bypass intended access controls and perform prohibited entity creation and modification actions via the backend API. Although Operators are documented and priced as unable to create or modify entities, the API fails to enforce this restriction on workspace endpoints, enabling privilege escalation to remote code execution within Windmill deployments.

Critical Impact

Operators can create and update scripts, flows, apps, and raw_apps. Combined with the ability to execute scripts via the jobs API, this allows direct privilege escalation to remote code execution within the Windmill deployment.

Affected Products

• Windmill versions 1.56.0 through 1.614.0
• All deployments using the Operator role introduced in version 1.56.0
• Self-hosted and cloud-hosted Windmill instances

Discovery Timeline

• April 7, 2026 - CVE-2026-22683 published to NVD
• April 8, 2026 - Last updated in NVD database

Technical Details for CVE-2026-22683

Vulnerability Analysis

This vulnerability stems from a fundamental disconnect between Windmill's documented role-based access control (RBAC) model and its actual API implementation. The Operator role was designed as a restricted permission tier—users who can execute workflows but cannot create or modify the underlying scripts, flows, or applications. However, the backend API endpoints responsible for workspace entity management failed to implement the corresponding authorization checks.

The impact is significant because Windmill is an open-source workflow automation platform where scripts can execute arbitrary code. An attacker with only Operator-level access can craft malicious scripts, deploy them through the unprotected API endpoints, and then execute them via the jobs API—achieving full remote code execution within the deployment context.

Root Cause

The root cause is a missing authorization check in multiple backend API handlers. The apps.rs, flows.rs, scripts.rs, and raw_apps.rs handlers in the windmill-api backend module accept requests from authenticated Operators without verifying whether the is_operator flag is set. This violates the principle of least privilege and contradicts the documented behavior of the Operator role.

Attack Vector

The attack vector is network-based and requires low-privileged authentication (Operator role). An attacker with valid Operator credentials can:

1. Authenticate to the Windmill API with Operator credentials
2. Send POST/PUT requests to workspace endpoints (/api/w/{workspace}/scripts, /api/w/{workspace}/flows, /api/w/{workspace}/apps)
3. Create a malicious script containing arbitrary code
4. Execute the script via the jobs API endpoint
5. Achieve remote code execution in the context of the Windmill worker process

// Security patch in backend/windmill-api/src/apps.rs
// Source: https://github.com/windmill-labs/windmill/commit/c621a74804f4f6e8318819c01e3a23a17698588b

     Path(w_id): Path<String>,
     multipart: Multipart,
 ) -> Result<(StatusCode, String)> {
+    if authed.is_operator {
+        return Err(Error::NotAuthorized(
+            "Operators cannot create apps for security reasons".to_string(),
+        ));
+    }
     let (path, _id) = process_app_multipart!(
         authed,
         user_db,

// Security patch in backend/windmill-api/src/flows.rs
// Source: https://github.com/windmill-labs/windmill/commit/c621a74804f4f6e8318819c01e3a23a17698588b

     Path(w_id): Path<String>,
     Json(nf): Json<NewFlow>,
 ) -> Result<(StatusCode, String)> {
+    if authed.is_operator {
+        return Err(Error::NotAuthorized(
+            "Operators cannot create flows for security reasons".to_string(),
+        ));
+    }
     check_scopes(&authed, || format!("flows:write:{}", nf.path))?;
     validate_flow(&nf).await?;
     if *CLOUD_HOSTED {

Detection Methods for CVE-2026-22683

Indicators of Compromise

• Unexpected script, flow, or app creation events in audit logs by Operator-role users
• API requests to /api/w/{workspace}/scripts, /api/w/{workspace}/flows, or /api/w/{workspace}/apps endpoints from Operator accounts
• Execution of newly created scripts by Operator users that were not previously authorized
• Unusual job execution patterns or new workflow entities appearing in workspaces

Detection Strategies

• Review Windmill audit logs for entity creation or modification events associated with Operator-role user accounts
• Monitor API access logs for POST/PUT requests to workspace endpoints from users with Operator permissions
• Implement alerting on any script, flow, or app creation by non-admin users
• Correlate job execution logs with entity creation timestamps to identify potential exploitation attempts

Monitoring Recommendations

• Enable verbose audit logging in Windmill to capture all API interactions
• Set up SIEM rules to detect unauthorized entity creation patterns
• Periodically audit all scripts, flows, and apps to identify unexpected or malicious entries
• Monitor network traffic for anomalous API request patterns targeting workspace endpoints

How to Mitigate CVE-2026-22683

Immediate Actions Required

• Upgrade Windmill to version 1.615.0 or later immediately
• Audit all Operator-role user accounts and their recent activity
• Review all scripts, flows, and apps created since deploying version 1.56.0 for unauthorized or malicious content
• Consider temporarily revoking Operator access until the patch is applied

Patch Information

Windmill Labs has released version 1.615.0 which includes the security fix. The patch adds explicit authorization checks for the is_operator flag in all relevant API handlers, returning an Error::NotAuthorized response when Operators attempt to create or modify workspace entities.

The security fix is tracked in commit c621a74804f4f6e8318819c01e3a23a17698588b. For more details, see the Windmill Labs Version Release.

Workarounds

• Restrict network access to the Windmill API to trusted IP ranges only until patching is complete
• Remove Operator role assignments temporarily and assign users to more restricted roles
• Deploy an API gateway or reverse proxy with custom rules to block POST/PUT requests to workspace endpoints from Operator users
• Implement additional network segmentation to isolate Windmill worker processes

# Configuration example - Nginx reverse proxy rule to block Operator entity creation
# Apply until Windmill is upgraded to 1.615.0+

# In your nginx server block, add upstream request inspection
# to reject unauthorized entity creation attempts
location ~ ^/api/w/[^/]+/(scripts|flows|apps|raw_apps)$ {
    # Block POST/PUT for Operator users at proxy level
    # Requires header injection from authentication layer
    if ($http_x_user_role = "operator") {
        return 403 "Operator role cannot create entities";
    }
    proxy_pass http://windmill_backend;
}