Description

Description Nimbus validated `topology.blobstore.map` against the calling subject at submission time only. The rebalance operation accepts configuration overrides and stripped a small set of keys from them, but never re-ran that validation, so a caller authorised to rebalance a topology could introduce a blobstore map entry naming a blob whose ACL does not grant them access. Supervisors localise whatever key the map names, placing the blob's contents into the topology's working directory. The same advisory covers `listBlobs`, which performed no authorization check and passed no subject, unlike the neighbouring `getBlobMeta` and `beginBlobDownload` operations. It therefore returned every key in the blobstore to any caller able to reach the Nimbus Thrift port, which provides the key names that make the above practical. On its own the disclosure is metadata only. Mitigation Upgrade to 3.1.0, where rebalance configuration overrides are validated exactly as submission-time configuration is, against the rebalancing caller, and where `listBlobs` applies the configured authorization. Users who cannot upgrade immediately should restrict rebalance rights to trusted principals, keeping in mind that membership of a topology's `topology.users` or `topology.groups` confers them. 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": "8.1",
  "pubDate": "2026-09-14T15:17:10.187Z",
  "pubdate": "2026-09-14T15:17:10.187Z",
  "executiveSummary": "Apache Storm is susceptible to multiple vulnerabilities involving insufficient authorization checks within the Nimbus component.\nThe first vulnerability is an improper authorization bypass during topology rebalancing, allowing unauthorized access to restricted blobstore content. The second is an information disclosure vulnerability in the listBlobs function due to the total absence of access control.\nThese flaws impact Nimbus, the master node of Apache Storm, potentially exposing sensitive data stored within the blobstore.\nAttackers can leverage the metadata leaked by listBlobs to identify target keys, then utilize the rebalance operation to inject unauthorized blob references.\nExploitation requires network access to the Nimbus Thrift port. Risk is elevated for environments where rebalance privileges are loosely assigned to principals that may be compromised.\nImmediate patching to version 3.1.0 is required to implement validation logic for rebalance configuration overrides and enforce authorization on blob discovery operations.",
  "technicalDetails": "The vulnerability resides in the Apache Storm Nimbus component, specifically within the handling of topology configuration and blobstore management. The primary issue stems from a failure to re-validate `topology.blobstore.map` entries during the rebalance operation.\nIn the affected versions, Nimbus only performs validation against the calling subject during the initial topology submission. During a rebalance, the system accepts configuration overrides but fails to re-verify the `topology.blobstore.map` against the subject requesting the rebalance. Consequently, an attacker with sufficient privileges to initiate a rebalance operation can inject arbitrary keys into the blobstore map. Because the supervisors treat this map as authoritative, they proceed to localize the requested blobs, effectively pulling unauthorized data into the topology's working directory.\nA secondary vulnerability exists in the `listBlobs` function within the Nimbus Thrift API. Unlike neighboring functions such as `getBlobMeta` and `beginBlobDownload`, `listBlobs` performs no authorization checks and does not receive a subject context. This allows any entity capable of reaching the Nimbus Thrift port to enumerate all keys stored within the blobstore. While this is primarily an information disclosure of metadata, it acts as a critical prerequisite for the aforementioned rebalance exploit by allowing attackers to discover valid, restricted key names.\nThe attack flow typically follows these steps: 1) An attacker connects to the Nimbus Thrift port and invokes `listBlobs` to harvest available blob keys. 2) The attacker identifies a target blob for which they lack legitimate access. 3) The attacker initiates a rebalance request for a topology they control, injecting the target blob key into the `topology.blobstore.map` override. 4) Nimbus processes the request without re-validating the map against the current caller. 5) Supervisors receive the configuration and localize the sensitive blob, granting the attacker access to the blob's contents within the working directory.\nThis vulnerability is present in versions prior to 3.1.0. The lack of secondary validation and the insecure design of the listBlobs API demonstrate a failure to enforce the principle of least privilege throughout the lifecycle of topology management operations."
}