Description

Description When launching a Docker or OCI worker, the setuid-root `worker-launcher` first changes ownership of the entire worker directory to the untrusted topology user, and only afterwards reads and acts on the command file that the supervisor wrote into that same directory. The file is opened without `O_NOFOLLOW` and without re-verifying its owner, so between the ownership change and the read the tenant can replace its contents. For the Docker path the parsed command is executed with real uid 0, and the command sanitiser is not a privilege boundary: it admits `-v` with an arbitrary source, `--device`, `--cap-add`, `--security-opt`, `--user` and `--net`, and copies positional arguments through verbatim. A rewritten file therefore yields an attacker-authored, root-equivalent container invocation with the host filesystem available. For the OCI path the same rewrite window applies, and mount validation is structural only, with no source or destination allow-list, so arbitrary host paths can be bind-mounted read-write into the container. The `username` field of the command file is likewise attacker-settable and is checked only against non-root and minimum-uid rules, permitting execution as another tenant's uid. Mitigation Upgrade to 3.1.0, where the command file is validated before the ownership change and re-verified on open, and where mount sources and destinations are constrained by configuration. Users who cannot upgrade immediately should disable Docker and OCI worker isolation, or restrict topology submission on affected supervisors to trusted principals. Note that the launcher must be rebuilt and reinstalled after upgrading. Credit The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-09-14T15:17:09.930Z",
  "pubdate": "2026-09-14T15:17:09.930Z",
  "executiveSummary": "The vulnerability involves a Time-of-Check to Time-of-Use (TOCTOU) race condition in the setuid-root 'worker-launcher' component used for Docker and OCI worker execution.\nBy manipulating the worker directory structure between an ownership change and a file read operation, an attacker can substitute command files to achieve arbitrary container configuration execution.\nThis flaw permits an untrusted tenant to escalate privileges to root on the host system or execute processes as another tenant's UID.\nThe vulnerability affects systems utilizing Docker or OCI worker isolation. Successful exploitation grants the attacker the ability to bind-mount host filesystems, bypass sanitization, and execute containers with elevated permissions.\nThe impact includes full host compromise or cross-tenant data access, posing a severe risk to multi-tenant environments relying on these worker isolation mechanisms.",
  "technicalDetails": "The root cause is a TOCTOU race condition within the 'worker-launcher' utility. When launching an OCI or Docker worker, the utility operates as setuid-root and performs a recursive ownership change of the worker directory to an untrusted topology user. Only after this change does the launcher read the command file written by the supervisor.\nBecause the file is opened without the 'O_NOFOLLOW' flag and lacks re-verification of file ownership, a malicious tenant can replace the legitimate command file with an attacker-authored version during the window between the 'chown' operation and the 'open' call.\nIn the Docker execution path, the command sanitizer is insufficient to serve as a privilege boundary. The 'worker-launcher' treats the attacker-controlled input as trusted, allowing the injection of unauthorized flags such as '-v' (for arbitrary volume mounts), '--device', '--cap-add', '--security-opt', '--user', and '--net'. By rewriting the command file, an attacker can force the container to run with host-equivalent privileges or map sensitive host paths into the container environment.\nIn the OCI execution path, the vulnerability allows for the bypass of structural mount validation. Because there is no strict allow-list for mount sources or destinations, attackers can bind-mount sensitive host directories into the container with read-write access. Furthermore, the 'username' field in the command file is not strictly validated against the intended user, allowing an attacker to impersonate other tenants and gain unauthorized access to their processes and data.\nThe attack flow proceeds as follows: 1) The supervisor initializes the worker directory. 2) The attacker monitor detects the directory creation. 3) The 'worker-launcher' starts the chown process. 4) The attacker replaces the command file with a malicious configuration before the launcher reads it. 5) The 'worker-launcher' reads the poisoned file and executes the container with malicious parameters as root or another target user, leading to host-level exploitation."
}