Description

Description The setuid-root `worker-launcher` binary adjusts ownership and permissions of worker directories by walking the tree with FTS and calling `lchown` and `chmod` on each entry's full pathname while running with an effective uid of 0. Both syscalls re-resolve the path at the time of the call, after FTS has classified the entry, and the trees being walked are owned and writable by the untrusted topology user. A tenant running code on a supervisor node could therefore replace an intermediate directory component with a symbolic link between classification and the privileged operation, redirecting the root-owned `lchown` or `chmod` at an arbitrary file on the host. The operation is repeatable at will, since crashing a worker forces a relaunch and blob updates re-run the walk, so a failed attempt costs the attacker nothing. This crosses the boundary that `supervisor.run.worker.as.user` and container isolation are intended to enforce. It is the same defect class as the Hadoop container-executor issues from which this code derives. Mitigation Upgrade to 3.1.0, where the privileged walk operates on file descriptors it has already stat'd rather than on pathnames re-resolved at call time. Users who cannot upgrade immediately should not run untrusted topology code on supervisors configured with `supervisor.run.worker.as.user`, since the launcher is the boundary being crossed. Note that the launcher must be rebuilt and reinstalled after upgrading; replacing the Java artifacts alone is not sufficient. 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.807Z",
  "pubdate": "2026-09-14T15:17:09.807Z",
  "executiveSummary": "The Apache Storm worker-launcher utility is susceptible to a Time-of-Check to Time-of-Use (TOCTOU) race condition vulnerability, categorized as a symlink attack.\nThe flaw exists within the setuid-root binary responsible for adjusting file system permissions and ownership during worker initialization.\nBy manipulating directory structures within untrusted user-controlled paths, a malicious actor can influence the binary to execute privileged lchown or chmod operations against arbitrary files on the host system.\nThis vulnerability effectively bypasses established container isolation boundaries and the supervisor.run.worker.as.user security configuration, potentially granting an attacker root-level access or control over arbitrary host files.\nThe exploitation process is repeatable and reliable, as the privileged operations are triggered during standard worker lifecycle events, such as worker relaunching or blob updates.\nThe vulnerability originates from the use of path-based operations that are susceptible to resolution changes between the directory tree traversal and the actual system call execution.\nImmediate mitigation requires upgrading to version 3.1.0 or higher and ensuring the reinstallation of the privileged binary.",
  "technicalDetails": "The root cause of this vulnerability is a race condition inherent in the implementation of the worker-launcher's directory tree traversal mechanism. The binary utilizes FTS (File Tree Traversal) to walk directory structures while operating with an effective user ID (EUID) of 0 (root).\nDuring this process, the binary performs permission and ownership adjustments by calling lchown and chmod on file paths discovered by FTS. Critically, these system calls resolve the provided pathname at the moment of execution rather than operating on the file descriptors or inode references validated during the initial traversal phase.\nBecause the directory trees being processed are writable by an untrusted topology user, the attacker can exploit the temporal gap between the FTS classification of a path component and the invocation of the privileged lchown or chmod syscalls.\nThe attack flow follows these steps: 1. The attacker monitors the supervisor node for worker-launcher execution (e.g., during worker startup or blob updates). 2. Upon identifying a target path currently being processed by the binary, the attacker replaces an intermediate directory component with a symbolic link pointing to a target sensitive file on the host (e.g., /etc/shadow or other root-owned configuration files). 3. The worker-launcher, having already passed its validation step for the original directory structure, proceeds to call the privileged syscalls using the attacker-controlled path. 4. The kernel resolves the symbolic link, causing the setuid-root binary to apply the chmod or lchown operation to the attacker's chosen target instead of the intended worker directory entry.\nThis behavior constitutes a classic TOCTOU vulnerability that crosses the security boundary enforced by container isolation and user-mapping configurations. Since the attacker controls the topology code, they can force worker crashes or blob update cycles to repeatedly attempt the race condition until successful exploitation occurs at no additional cost to the attacker.\nThe flaw affects versions prior to 3.1.0. The vulnerability is fundamentally a design flaw in how the binary handles file system operations on untrusted paths, mirroring historical security deficiencies found in Apache Hadoop's container-executor utility."
}