SURIQ
The CVSS score for CVE-2026-29059 reads 7.5, the number the industry files under high but not an emergency. That number describes a standalone Windmill install. It undersells what happens on the way most teams really run the platform, where the same unauthenticated file read hands an attacker a working path to superadmin code execution.
Windmill is an open-source platform for internal automation: APIs, background jobs, workflows, and small UIs that teams stand up to run their own operations. VulnCheck reported this week that the flaw is being exploited in the wild, with researcher Valentin Lobstein observing attempts against roughly 170 exposed instances across 24 countries. The bug was fixed in January. It is being mass-probed in July. That gap is the story.
Why a file-read bug can end in full control
The flaw lives in the workspace log-fetch route, the one whose handler is named get_log_file. It accepts a filename parameter and joins that value into a server path without sanitizing it, so a request carrying ../ sequences walks out of the intended directory and pulls back whatever file it points at. No credentials are required. Early exploitation attempts went straight for /etc/passwd, the standard proof that traversal works.
Reading /etc/passwd is noise. The consequential target is /proc/1/environ, the environment of the container's main process. Windmill's own guidance has operators pass a SUPERADMIN_SECRET as an environment variable in orchestrated and containerized deployments. When that secret sits in the process environment, the same unauthenticated read pulls it out, and it doubles as a bearer token. An attacker who holds it authenticates as a superadmin and runs code through the job preview API. The variable is not set by default, so a bare standalone instance is limited to file disclosure. The common production topology is not a bare standalone instance.
This is the exposure the 7.5 hides. The score is anchored to confidentiality impact on the default case, while the deployment pattern Windmill documents for real use turns the same primitive into remote code execution. We saw the identical score-versus-reality gap with Budibase's file-read flaw, where reading a server's secrets was the whole game, and with Argo CD's unauthenticated takeover path inside clusters. Internal tools that hold platform credentials do not get to be medium.
A six-month patch gap, not a zero-day
Version 1.603.3 carried the fix, out since January 2026. Exploitation surfaced in July. Nothing about the vulnerability changed in between. What changed is that public understanding of it caught up to the population of servers that never updated. Roughly 170 reachable instances is not a large number in absolute terms, but every one is an internal automation hub with credentials, source, and job history sitting behind it.
Windmill belongs to a category that routinely escapes patch cycles: self-hosted developer and automation tooling that a team installs once, wires into everything, and then forgets. It rarely sits in the same inventory as the operating system or the public web app, so it does not ride the normal patch cadence. We flagged the same blind spot with self-hosted GitLab and with Crawl4AI shipping its server open by default. The recurring lesson is that if a tool can reach your secrets, it belongs on the asset list you truly patch, not the one you mean to.
Detection you can run before you finish patching
You do not need the update in place to start looking for this. The exploitation signature is legible in access logs: requests to the get_log_file path carrying ../ sequences, or targeting /proc/ and especially /proc/1/environ and /proc/self/environ. Those are not paths a legitimate log fetch ever needs.
Watch the proxy too, not just the app. VulnCheck observed hits against both direct Windmill endpoints and a Nextcloud reverse-proxy path fronting an instance, which means a proxy in front of Windmill is not a shield. A reverse proxy that forwards the request path without filtering traversal simply relays the attack. If Windmill sits behind a proxy you assumed was protecting it, check that proxy's logs with the same signatures.
Patch to 1.603.3, then rotate any secret that touched this box
Update self-hosted Windmill to 1.603.3 or later. That is the version that added the sanitization check. Then treat the credentials as potentially seen. If SUPERADMIN_SECRET was ever set as an environment variable on an exposed instance, rotate it. Patching closes the read, but it does not invalidate a token an attacker already copied during the window. Rotate the other secrets Windmill held for its jobs while you are there, and grep your access logs back to January for the traversal signatures above before you call it clean. This is the discipline that the Branda WordPress flaw demanded: a fix that lands in January means nothing if the box sat unpatched until the exploit went public.