Windmill CVE-2026-47107: Brief Summary of Cross Tenant DNS Poisoning via nsjail Sandbox Misconfiguration

Introduction

A single non recursive read only remount in Windmill's nsjail sandbox configuration left critical Kubernetes injected files writable inside script execution jails, enabling any authenticated user to persistently poison DNS resolution and intercept credentials across every tenant sharing the same worker pod. With a CVSS score of 9.6 and a straightforward exploitation path requiring nothing more than the ability to run a sandboxed script, CVE-2026-47107 represents a serious exposure for multi tenant Windmill deployments.

Windmill is an open source developer platform (AGPLv3) that provides infrastructure for internal APIs, background jobs, and workflows. It is used by organizations to orchestrate automation pipelines and offers multiple layers of process isolation, including nsjail sandboxing, to protect infrastructure from malicious code. Its relevance here is that multi tenant deployments share long lived worker pods, making any sandbox escape a cross tenant concern.

Technical Information

Root Cause: Non Recursive Read Only Remount

The vulnerability stems from how nsjail applies mount namespace restrictions in Kubernetes environments. Windmill's nsjail configuration files mount the entire /etc directory as read only. For ordinary files that exist directly on the filesystem, this is effective. However, in Kubernetes, the kubelet injects specific files into /etc as separate bind mounts layered on top of the directory. These include /etc/hosts, /etc/resolv.conf, and /etc/hostname.

The critical detail is that nsjail applies its read only remount non recursively. The classic mount syscall does not propagate the read only status to submounts. As a result, the kubelet injected files remain fully writable inside the jail, even though the parent /etc directory is mounted read only.

Writable Targets

The following table summarizes the confirmed writable files and their sourcing:

Attack Flow

The exploitation path proceeds as follows:

1. Initial access: An authenticated user with permission to execute scripts in any Windmill workspace submits a job that runs inside the nsjail sandbox.

2. File modification: From within the sandbox, the attacker writes malicious entries to the writable files. For example, appending entries to /etc/hosts to redirect legitimate hostnames to attacker controlled IP addresses, or modifying /etc/resolv.conf to point DNS resolution at an attacker controlled resolver.

3. Persistence via pod reuse: Windmill worker pods are long lived and reused across all workspaces and tenants. The poisoned file entries persist at the pod level for the lifetime of the worker pod. Every subsequent job executed on that same pod inherits the poisoned configuration.

4. Cross tenant impact: When a victim in a different tenant runs a script on the same worker pod, their job's network traffic is subject to the attacker's DNS and host redirections. This enables:

   • Redirecting hostnames to attacker controlled servers via /etc/hosts
   • Intercepting all DNS queries via a rogue resolver in /etc/resolv.conf
   • Performing transparent HTTPS man in the middle attacks if /etc/ssl/certs/ca-certificates.crt is also writable (by injecting a rogue CA certificate)
   • Intercepting WM_TOKEN JWTs, which grants workspace admin access to victim workspaces

5. Credential theft and lateral movement: With intercepted WM_TOKEN JWTs, the attacker gains workspace admin privileges in victim workspaces across tenant boundaries, enabling further data exfiltration or supply chain attacks via package registry redirection.

Why This Is Particularly Dangerous

The combination of factors makes this vulnerability especially impactful: the attack requires only low privilege (any authenticated user who can run a script), the persistence mechanism is automatic (pod reuse), and the blast radius spans all tenants on the affected worker. There is no indication to the victim that their DNS resolution has been tampered with.

The Fix in Version 1.703.2

The patch, delivered in Pull Request #9194, adds explicit read only per file binds for the affected files across all eighteen nsjail configuration files. These explicit binds shadow the writable kubelet submounts with a read only view of the same content, neutralizing the non recursive remount issue.

Importantly, this fix only applies to the nsjail isolation mode. The "unshare" and "none" isolation modes do not use mount namespaces and are not covered by this patch:

Affected Systems and Versions

All versions of Windmill prior to 1.703.2 are affected when using the nsjail isolation mode in Kubernetes deployments. The vulnerability specifically requires:

• Windmill versions before 1.703.2
• nsjail isolation mode enabled
• Deployment on Kubernetes (where the kubelet injects bind mounts into /etc)
• Multi tenant configuration with shared worker pods

Single tenant deployments or deployments not running on Kubernetes may not be affected by the kubelet submount behavior, though this should be validated independently.

Vendor Security History

Windmill has experienced several notable security issues in the recent period:

This pattern of vulnerabilities centered on access control and isolation boundaries is worth noting for organizations that depend on Windmill in security sensitive contexts. The maintainers have been responsive in addressing reported issues, but the recurrence suggests that a more systematic review of isolation and permission boundaries may be warranted.

References

• VulnCheck Advisory: Windmill < 1.703.2 Incorrect Default Permissions in nsjail Configuration
• Windmill Pull Request #9194: Fix cross tenant DNS poisoning via writable /etc in nsjail
• Windmill Commit f8467f3
• Windmill Release v1.703.2
• Windmill Security and Process Isolation Documentation
• GHSA-24fr-44f8-fqwg: SUPERADMIN_SECRET Exposure