CVE-2026-82441 in Storm Nimbus
Summary
by MITRE • 09/14/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/14/2026
The vulnerability described involves a critical lack of input validation within Apache Storm's Nimbus component, specifically concerning the handling of dependency lists submitted during topology deployment. When a user submits a new topology, they provide two distinct lists: `dependency_jars` and `dependency_artifacts`. These lists contain keys that reference blobs stored in the cluster's blobstore. The core technical flaw lies in the fact that while clients populate these fields after uploading their respective blobs to the storage system, Nimbus performs no validation on the contents of these lists at submission time. This absence of verification allows a malicious or careless user to specify arbitrary blob store keys within their topology configuration, rather than being restricted solely to the dependencies they actually uploaded and own.
The operational impact manifests in two severe scenarios due to this unchecked input. First, during the cleanup phase of a finished topology, Nimbus iterates through the provided dependency lists and deletes the corresponding blobs from the storage system. Because these deletions are executed under the authority of the Nimbus service account, they bypass standard access control list checks that would normally prevent unauthorized users from deleting data belonging to other tenants or topologies. Consequently, an attacker can submit a topology with `dependency_jars` pointing to critical files owned by another active topology, such as its primary `-stormjar.jar`. When the malicious topology completes and is cleaned up, it triggers the deletion of these essential artifacts for the legitimate topology, effectively destroying that application's ability to run or be resubmitted.
Secondly, a more catastrophic failure mode occurs during leader election processes within the Nimbus cluster. Upon acquiring leadership, a Nimbus node validates the integrity of all active topologies by checking if their listed dependency keys still exist in the blobstore. If any key referenced by an active topology is missing, the logic dictates that the current leader must surrender its role to trigger a re-election and potential recovery process. However, because this check applies globally to all active topologies, a single invalid or deleted key from one compromised topology causes every Nimbus node to repeatedly acquire leadership only to immediately surrender it again when they detect the discrepancy. This results in an infinite loop of leader elections where no node successfully retains leadership for long enough to perform cluster management tasks such as scheduling jobs, cleaning up old data, or accepting new submissions, effectively rendering the entire Storm cluster unavailable and unmanageable.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation, as the system fails to verify that user-supplied input conforms to expected constraints before processing it. Furthermore, the ability of an authenticated but unauthorized user to delete resources belonging to other users via improper ACL enforcement relates closely to CWE-732 Permission Issues and CWE-611 Information Exposure Through Unrestricted Search in the context of data integrity loss. In terms of attack vectors, this represents a form of Denial of Service (CWE-400) achieved through resource exhaustion or state corruption, leveraging improper access control mechanisms that allow privilege escalation from simple submission rights to destructive administrative actions against shared infrastructure components like the blobstore.
The recommended mitigation is to upgrade immediately to version 3.1.0 or later, where the Nimbus component has been patched to enforce strict validation rules on topology submissions. In the fixed versions, every entry in both `dependency_jars` and `dependency_artifacts` must correspond to a valid dependency blob key that actually exists within the blobstore at the time of submission. This ensures that users can only reference resources they have legitimately uploaded and are authorized to manage. It is crucial for operators to note that this patch applies retroactively only to new submissions; topologies already deployed on affected versions with invalid lists will continue to pose a risk until those specific topology configurations are removed or resubmitted correctly.
For clusters experiencing leader instability due to existing malformed topologies, immediate remediation requires manual intervention by cluster administrators. Operators should inspect the Nimbus logs for error messages indicating missing dependency keys and identify the offending topology. Once identified, the administrator must either remove the problematic topology from the cluster or force a re-submission with corrected dependency lists that only reference valid, existing blobs. In environments where upgrading is not immediately feasible due to operational constraints, the primary defense-in-depth strategy is to restrict topology submission privileges exclusively to trusted and vetted principals who can be relied upon to provide accurate metadata, thereby reducing the attack surface for this specific input validation flaw.