Windmill: Resource-scoped API tokens can read script contents outside their allowed path via scripts/list_search

CISA KEV is observed exploitation evidence. FIRST EPSS is a dated prediction of exploitation in the next 30 days. Missing scores are unknown. This collector requests predictions only for explicit CVE aliases in the public NuGet archive; Microsoft release views retain their existing prediction scope.

No collected risk observation for these identifiers. This does not establish absence of exploitation or a zero probability.

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.

Source published

20 Aug 2026 16:47:41 UTC

Source modified

21 Aug 2026 21:47:02 UTC

Observed here

23 Oct 2026 15:48:27 UTC

Source terms

CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: cve-program · CVE Program Terms of Use. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 4.0 · 5.1 CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N

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.

Source published

Aug 20, 2026, 4:47:41 PM (timezone not stated)

Source modified

Aug 21, 2026, 9:47:02 PM (timezone not stated)

Observed here

7 Nov 2026 12:28:36 UTC

Source terms

ENISA EUVD · source terms and attribution apply

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: euvd · ENISA EUVD · source terms and attribution apply. Source text is retained; field grouping and change labels are provided by ChangeIntel.

EUVD CVSS 4.0 · 5.1 CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N

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.

Source published

20 Aug 2026 17:18:17 UTC

Source modified

18 Oct 2026 20:10:00 UTC

Observed here

25 Oct 2026 13:17:22 UTC

Source terms

NIST NVD usage terms; underlying source attribution retained

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: nvd · NIST NVD usage terms; underlying source attribution retained. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 4.0 · [email protected] · Secondary · 5.1 CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

### Summary A resource-scoped API token can read script contents outside its allowed path scope via `GET /api/w/{workspace}/scripts/list_search`. This appears to be a remaining variant of the scoped-token authorization class previously addressed for other endpoints. The route-level scope middleware validates the token domain/action, but does not enforce the resource/path segment of a scope. `scripts/list_search` then returns script `path` and `content` for scripts in the workspace without applying per-row path filtering against the token scopes. ### Affected endpoint `GET /api/w/{workspace}/scripts/list_search` ### Affected versions Confirmed in the current public repository code and believed to affect the latest published release at the time of review: `<= 1.714.1` Patched version: unknown. ### Details Windmill supports scoped API tokens with scopes in the format: `{domain}:{action}[:{resource}]` The parser supports resource-scoped values such as: `scripts:read:f/allowed/*` and the codebase contains helpers for resource matching, including wildcard matching. However, the route-level scope check used for requests with scoped API tokens only validates the route domain and action. It does not compare the token's resource/path restriction against the requested route or against the rows returned by list endpoints. For `scripts/list_search`, the handler returns `path` and `content` for scripts in the workspace: `SELECT path, content from script WHERE workspace_id = $1 AND archived = false LIMIT $2` There is no additional `check_scopes(...)` call in the handler and no per-row filtering based on the token's resource/path scope. As a result, a token intended to read only scripts under one path prefix may be able to read script contents from unrelated paths in the same workspace. ### Source-level reproduction 1. Create or use a workspace containing at least two scripts: - `f/allowed/script_a` - `f/private/script_b` 2. Create a scoped API token intended to read only the allowed path: `scripts:read:f/allowed/*` 3. Use that token to call: `GET /api/w/{workspace}/scripts/list_search` 4. Expected behavior: The response should include only scripts matching the token's resource scope, e.g. only scripts under: `f/allowed/*` 5. Actual behavior from source review: The route-level scope check accepts the request as `scripts:read`, and the handler returns script `path` and `content` for scripts in the workspace without filtering the rows by the token's resource scope. This can expose script source code from paths outside the token's intended scope. ### Impact A user or integration holding a path-restricted `scripts:read:{resource}` token may be able to read script contents from unrelated scripts in the same workspace. Depending on how scripts are used, this may disclose: - internal automation logic, - integration details, - business logic, - inline configuration, - accidentally hardcoded secrets or credentials. This does not require admin privileges. It requires possession of a valid scoped API token for the workspace. ### Related context This appears related to the broader class of issues where route-level token scope enforcement validates domain/action but not the resource/path portion of the scope. Similar scoped-token issues appear to have been fixed for other endpoints, such as resources/variables listing and job preview/run paths, but I did not find an equivalent fix for `scripts/list_search`. ### Suggested fix Apply resource/path scope enforcement to `scripts/list_search`. Possible approaches: 1. Add explicit handler-level authorization similar to per-resource endpoints. 2. Filter returned rows so that a scoped token only receives scripts whose `path` is included by at least one `scripts:read:{resource}` scope. 3. Add regression tests for: - `scripts:read:f/allowed/*` cannot see `f/private/script_b`, - broad `scripts:read` still sees all accessible scripts, - unscoped tokens preserve current behavior, - filter-tag-only tokens preserve current compatibility behavior. A more defensive long-term fix would be to make route-level scope enforcement aware of resource/path restrictions where the route contains a concrete resource path, while list endpoints should apply per-row filtering.

Source published

10 Jul 2026 19:28:06 UTC

Source modified

10 Jul 2026 19:41:39 UTC

Observed here

24 Oct 2026 13:19:54 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS_V4 · CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N

Publisher rating · MODERATE