Description

Description When ZooKeeper authentication is configured, Storm deliberately retains `storm.zookeeper.topology.auth.payload` in the topology configuration, because workers need it. Nimbus then served that configuration verbatim to any caller holding read-only topology permissions, so a user whose only grant was the ability to view a topology received its ZooKeeper credential. That credential is not read-only. The cluster state implementation uses write-capable ACLs for worker heartbeats, backpressure and error state, so a recipient can forge or remove that state for the topology concerned. It is not a write credential on assignments. The same advisory covers the submission client, which logged the generated payload at INFO on every submission that generated one, and the SASL handlers, which logged it at DEBUG. The credential therefore also reached any log aggregation or support bundle collected from the cluster. Mitigation Upgrade to 3.1.0, where the payload is removed from the configuration served to read-only callers and is no longer written to logs. Users who cannot upgrade immediately should rotate `storm.zookeeper.topology.auth.payload` for existing topologies, review retained logs and support bundles for the value, and restrict read-only topology permissions to trusted principals. 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": "6.5",
  "pubDate": "2026-09-14T15:17:10.453Z",
  "pubdate": "2026-09-14T15:17:10.453Z",
  "executiveSummary": "This vulnerability involves the improper exposure of ZooKeeper authentication credentials (storm.zookeeper.topology.auth.payload) within Apache Storm. The system inadvertently serves these credentials in topology configurations to users with read-only permissions and logs the sensitive data in plain text.\nThe vulnerability allows unauthorized users with read-only access to obtain write-capable ZooKeeper credentials. Although limited to specific cluster states such as heartbeats, backpressure, and error reporting, the exposure facilitates potential tampering with topology health metrics and operational state.\nThe issue affects Apache Storm versions prior to 3.1.0. Attackers can exploit this by simply requesting topology configurations or accessing centralized logging and support bundle repositories where the credentials have been persisted.\nThe risk is categorized as high due to the exposure of authentication material, which enables unauthorized modification of ZNode data, potentially leading to denial-of-service, misleading monitoring data, or further compromise of topology integrity.",
  "technicalDetails": "The root cause of this vulnerability lies in the insecure handling of the 'storm.zookeeper.topology.auth.payload' configuration object within Apache Storm. When ZooKeeper authentication is active, the Nimbus service requires workers to possess this payload to interact with the ZK quorum. However, the Nimbus server fails to redact this sensitive authentication material when responding to configuration requests from clients possessing only read-only topology permissions.\nFurthermore, the submission client and SASL authentication handlers exacerbate the exposure by logging the generated payload at INFO and DEBUG levels, respectively. This results in the credential being written to persistent log files and bundled support archives, significantly expanding the attack surface beyond the active Nimbus API.\nThe attack flow for unauthorized credential retrieval is as follows: 1) An attacker authenticates as a user with read-only topology permissions. 2) The attacker invokes the Nimbus service to retrieve the topology configuration. 3) The service returns the full configuration object, including the 'storm.zookeeper.topology.auth.payload', without filtering. 4) The attacker extracts the credential from the returned JSON/object.\nPost-exploitation, the attacker possesses credentials that are not strictly read-only within the ZooKeeper environment. While the credentials do not provide write access to the entire cluster or allow for the modification of topology assignments, they grant the attacker the ability to interact with ZNodes associated with worker heartbeats, backpressure mechanisms, and error reporting states. Consequently, an attacker can forge heartbeat signals to mask actual failures, trigger unnecessary topology rebalancing via backpressure manipulation, or inject falsified error states to disrupt cluster monitoring and stability.\nThe vulnerability is present in all deployments where ZK authentication is configured prior to the 3.1.0 release. It does not require complex exploit code; it leverages the intended functionality of the Storm API and the availability of unencrypted logs."
}