Hackers Exploit Windmill Flaw to Read Arbitrary Server Files Without Authentication

A high-severity security vulnerability in Windmill, the popular open-source developer platform used to build internal tools and workflows, is being actively exploited in the wild according to threat intelligence firm VulnCheck. The flaw — tracked as CVE-2026-29059 — is an unauthenticated path traversal vulnerability that allows attackers to read arbitrary files from the server without any credentials.

What Is Windmill?

Windmill is an open-source platform that lets developers build internal tools, scripts, workflows, and automations. It's widely used for tasks like connecting APIs, building admin dashboards, automating data pipelines, and creating internal ops tooling. Windmill deployments often sit on internal infrastructure and handle sensitive credentials, API keys, and configuration files — making them a valuable target for attackers.

CVE-2026-29059: Unauthenticated Path Traversal

The vulnerability exists in Windmill's get_log_file endpoint (/api/w/*/jobs/completed/get_log/<job_id>). The endpoint is designed to retrieve log files for completed workflow jobs, but due to insufficient path validation, an attacker can craft a request that traverses outside the intended log directory and reads arbitrary files from the server's filesystem.

Attack Mechanics

A path traversal attack exploits insufficient sanitization of user-supplied file paths. When get_log_file receives a job ID containing traversal sequences like ../../, the server resolves these relative paths and accesses files outside the log directory.

A proof-of-concept request might look like:

GET /api/w/default/jobs/completed/get_log/../../../../../../etc/passwd

On a vulnerable Windmill instance, this returns the contents of /etc/passwd. More impactful targets include:

• /etc/shadow — password hashes
• Environment files (.env) containing API keys and database credentials
• Windmill's own configuration files with database connection strings
• SSH private keys in /root/.ssh/ or user home directories
• Cloud provider credential files (~/.aws/credentials, ~/.config/gcloud/)

Why This Is Particularly Dangerous

Windmill is a developer workflow platform — by design, it stores and processes sensitive credentials. Developers configure integrations with databases, cloud providers, third-party APIs, and internal services. A successful path traversal attack can immediately yield:

• Database credentials connecting Windmill to production databases
• Cloud API keys (AWS, GCP, Azure) with broad permissions
• Third-party SaaS tokens (Slack, GitHub, Jira, etc.)
• Internal service secrets configured as Windmill variables

This makes Windmill a particularly high-value target compared to a generic web application: the attacker can chain the path traversal into a full credential compromise without needing to progress further in the attack kill chain.

Active Exploitation Confirmed

VulnCheck confirmed that CVE-2026-29059 is being exploited in the wild. Organizations running Windmill — especially internet-facing or self-hosted instances accessible without VPN — should treat this as an emergency.

Immediate Mitigation Steps

1. Upgrade Windmill Immediately

Apply the patched version of Windmill that addresses CVE-2026-29059. Check the Windmill GitHub repository and release notes for the minimum safe version.

# If running via Docker, pull the latest patched image
docker pull windmill/windmill:latest
docker compose up -d windmill
 
# Verify the running version
docker exec <windmill-container> windmill --version

2. Restrict Network Access

If you cannot patch immediately, restrict access to your Windmill instance to trusted IP ranges only. Windmill should never be exposed directly to the public internet.

# Example: restrict access via iptables to internal network only
iptables -A INPUT -p tcp --dport 8000 -s 10.0.0.0/8 -j ACCEPT
iptables -A INPUT -p tcp --dport 8000 -j DROP

3. Audit for Exploitation

Check your Windmill access logs for path traversal patterns:

# Search access logs for traversal sequences
grep -E "\.\./|%2e%2e%2f|%2e%2e/" /var/log/windmill/access.log
 
# Check for requests to the vulnerable endpoint with suspicious job IDs
grep "get_log" /var/log/windmill/access.log | grep -E "\.\.|%2e"

Look for any unexpected file access patterns, particularly requests returning HTTP 200 with unusually large response bodies from the log endpoint.

4. Rotate All Credentials Stored in Windmill

If you have any indication that your instance was accessed before patching, immediately rotate:

• All API keys and tokens configured as Windmill variables or secrets
• Database credentials used by Windmill scripts and workflows
• Cloud provider credentials accessible from the Windmill environment
• Any service account tokens or OAuth credentials

5. Review Windmill's Attack Surface

Audit what files are accessible from the filesystem where Windmill runs:

• Avoid running Windmill as root
• Use Docker volume mounts that limit what filesystem paths the container can access
• Store sensitive credentials in a dedicated secrets manager (HashiCorp Vault, AWS Secrets Manager) rather than directly in Windmill variables

Detection: Indicators of Compromise

Access Log Patterns:

• Requests to /api/w/*/jobs/completed/get_log/ with job IDs containing ../, ..%2F, or %2e%2e
• Unusual HTTP 200 responses from the log endpoint with file-like content
• Requests from unexpected source IPs to internal Windmill instances

Filesystem Indicators:

• Unexpected access times on sensitive files like /etc/passwd, .env, or credential files
• New outbound network connections from the Windmill container/server to external IPs shortly after suspicious log requests

Resources

• The Hacker News: Windmill Flaw Report
• Windmill GitHub Repository
• VulnCheck Threat Intelligence
• NVD: CVE-2026-29059
• CWE-22: Path Traversal