Description

Description A topology's `topology.blobstore.map` lets the submitter choose a local name for each blob that the supervisor localises. That name was used to build a path under the topology's working directory without normalisation, in both `AsyncLocalizer` and `Container.createBlobstoreLinks`, and the symlink helper force-deletes whatever already exists at the target before creating the link. A submitter could therefore use `../` segments to direct that delete-and-symlink operation at an arbitrary path, as the supervisor user, on every node the topology is scheduled onto. The consequences include recursive deletion of supervisor-owned content and planting a symlink that causes a subsequent worker launch to execute attacker-chosen code as another tenant's operating-system user, which defeats the isolation that `supervisor.run.worker.as.user` is intended to provide. Mitigation Upgrade to 3.1.0, where the resolved target must lie inside the expected root at both call sites. Users who cannot upgrade immediately should restrict topology submission to trusted principals, and may reject submissions whose `topology.blobstore.map` entries contain path separators or `..` segments before they reach Nimbus. 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.553Z",
  "pubdate": "2026-09-14T15:17:09.553Z",
  "executiveSummary": "This vulnerability is a path traversal flaw within Apache Storm's blobstore localization mechanism.\nIt allows an authenticated topology submitter to perform unauthorized file system operations by injecting '..' segments into the `topology.blobstore.map` configuration.\nThe vulnerability affects the supervisor's ability to safely localize blobs, as the application fails to normalize paths when constructing file system links within the topology working directory.\nThe primary impact is arbitrary file deletion and potential code execution. An attacker can force the supervisor process to delete files it has permissions to access or replace critical files with symlinks.\nBy manipulating these symlinks, an attacker can trick subsequent worker launches into executing malicious code, thereby bypassing the isolation enforced by `supervisor.run.worker.as.user`.\nThe vulnerability poses a severe risk to multi-tenant environments where the supervisor operates with elevated privileges, as it allows for cross-tenant compromise.\nExploitation requires the ability to submit a topology to the cluster; therefore, restricting topology submission to trusted principals is a critical immediate defensive measure.",
  "technicalDetails": "The root cause of this vulnerability lies in the insufficient validation and lack of path normalization for blob names defined in `topology.blobstore.map`. Both the `AsyncLocalizer` and the `Container.createBlobstoreLinks` functions construct file paths under the topology working directory by directly concatenating the user-provided blob name.\nBecause the application does not normalize these paths or verify that the resulting destination resides within the expected working directory, an attacker can supply blob names containing directory traversal sequences such as '../'.\nThe vulnerability is further exacerbated by the symlink helper logic, which performs a forced deletion of any existing file or directory at the target location before creating the new symbolic link. This forced delete operation is executed with the privileges of the supervisor user.\nThe attack flow follows these steps: First, an attacker submits a topology with a crafted `topology.blobstore.map` entry containing traversal sequences that point to a sensitive system file or a target directory outside the working space. Second, upon scheduling the topology, the supervisor process initiates the localization process. Third, the `AsyncLocalizer` or `Container.createBlobstoreLinks` interprets the traversal sequences, resolving the target path to an arbitrary location on the supervisor node. Fourth, the symlink helper executes a force-delete on the targeted path. Finally, the supervisor establishes a symlink that points the target location to a resource controlled by the attacker.\nThis mechanism allows for a destructive impact, such as the recursive deletion of supervisor-owned content. More critically, it enables a payload delivery scenario where the attacker plants a malicious file and uses the symlink to redirect a legitimate worker launch process to execute this code. This action effectively invalidates the security boundary defined by `supervisor.run.worker.as.user`, allowing an attacker to execute code as another tenant's operating-system user.\nThe vulnerability affects versions prior to 3.1.0. The exploit is limited to users who have permissions to submit topologies, though in many production environments, this represents a significant attack vector against the shared infrastructure nodes."
}