Description

Description A submitted topology carries two lists of blobstore keys, `dependency_jars` and `dependency_artifacts`, which the client fills in after uploading the corresponding blobs. Nimbus performed no validation of their contents on the submission path, yet acts on them in two places. During cleanup of a finished topology, Nimbus deletes the keys named in those lists, and the deletion is performed as the Nimbus subject, for which the blobstore short-circuits its ACL check. A submitter who listed a key belonging to another topology, such as its `-stormjar.jar`, could therefore cause that blob to be deleted when their own topology was cleaned up. Separately, on acquiring leadership a Nimbus compares the dependency keys of all active topologies against the blobstore contents and surrenders leadership if any is missing. A single key that does not exist, on a single active topology, therefore causes every Nimbus to acquire leadership, surrender it and requeue indefinitely, leaving the cluster without a leader and unable to schedule, clean up or accept submissions. Mitigation Upgrade to 3.1.0, where a submission is refused unless every entry in both lists is a dependency blob key and exists in the blobstore. Note that this validates new submissions only; a topology stored by an affected version with an invalid list is unaffected by the upgrade. An operator whose cluster is failing to retain a leader should inspect the Nimbus log for the dependency keys reported as missing and remove or resubmit the topology naming them. Users who cannot upgrade immediately should restrict topology submission to trusted principals. Credit This issue was discovered by rzo1 while investigating an unrelated blobstore defect.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.1",
  "pubDate": "2026-09-14T14:17:12.590Z",
  "pubdate": "2026-09-14T14:17:12.590Z",
  "executiveSummary": "The Apache Storm Nimbus component is vulnerable to an improper authorization flaw related to blobstore key management within topology submissions. The vulnerability arises from a lack of validation regarding the contents of 'dependency_jars' and 'dependency_artifacts' lists during the topology submission process.\nThe primary impact is twofold: unauthorized arbitrary file deletion and potential Denial of Service (DoS) of the cluster leadership.\nAn authenticated user can exploit this vulnerability to force the Nimbus service to delete critical system blobs—such as other topologies' JAR files—by referencing them in their own topology's dependency lists. Furthermore, by referencing non-existent keys, an attacker can trigger a leadership instability loop where Nimbus instances continuously surrender leadership, effectively halting cluster operations.\nThe vulnerability affects systems where topology submission is not restricted to trusted principals. Exploitation requires the ability to submit a topology to the cluster. This issue represents a significant risk to cluster integrity and availability in multi-tenant environments where submitters are not fully trusted.",
  "technicalDetails": "The root cause of this vulnerability is the absence of server-side validation for blobstore keys submitted within the 'dependency_jars' and 'dependency_artifacts' lists during topology creation. Nimbus blindly trusts these lists and subsequently utilizes them with elevated privileges.\nThe first attack vector involves unauthorized deletion. When a topology is finished and scheduled for cleanup, Nimbus iterates through the submitted dependency lists and triggers a deletion process. Because this cleanup is performed under the Nimbus subject, the blobstore's ACL checks are bypassed. An attacker can craft a topology submission containing blob keys belonging to other users or system-critical components. Once the attacker's topology is cleaned up, the Nimbus service performs the deletion of these targeted keys, leading to data loss and potential service disruption for other users.\nThe second attack vector results in a cluster-wide Denial of Service. Upon acquiring leadership, the Nimbus daemon performs a validation check by comparing the dependency keys of all active topologies against the actual contents of the blobstore. If any key referenced in an active topology is missing, the Nimbus node surrenders its leadership. An attacker can deliberately submit a topology that includes a reference to a non-existent blob key. This causes every Nimbus node in the cluster to identify the missing resource, surrender leadership, and enter an indefinite requeue loop. This sequence prevents the cluster from scheduling new tasks, cleaning up existing ones, or accepting new submissions.\nThe attack flow for unauthorized deletion begins with the submission of a malicious topology via the standard Storm submission API. The attacker identifies the target key (e.g., another topology's '-stormjar.jar') and includes it in the submission metadata. The attacker waits for the job to complete; upon termination, the Nimbus cleanup routine executes the unauthorized deletion. The leadership DoS attack follows a similar submission flow but leverages the consistency check mechanism triggered by leadership election. Both vectors require the attacker to have topology submission capabilities but bypass the standard blobstore authorization layers due to the flawed validation logic within the Nimbus submission path."
}