Description

Description Nimbus accepted the `uploadedJarLocation` argument of `submitTopology` / `submitTopologyWithOpts` as a server-side path and opened it directly, without checking that it referred to a file the caller had actually uploaded. The intended flow is that a client first calls `beginFileUpload`, which returns a path inside the Nimbus inbox, and uploads the jar in chunks to that location; nothing bound submission to that flow, and the `uploaders` map populated by `beginFileUpload` was never consulted at submit time. An authenticated user with topology submission rights could therefore submit any path readable by the Nimbus daemon user as their topology jar. Nimbus copied the file into the topology's jar blob, and the blob ACL grants the submitting subject read access, so the contents could then be retrieved with the ordinary blob download RPCs. Candidate targets include the Nimbus Kerberos keytab, Thrift and UI TLS private keys, and `storm.yaml` with the ZooKeeper authentication payload. Possession of the Nimbus keytab turns an ordinary tenant into a cluster administrator. In a deployment configured as the documentation recommends, submission is available to every authenticated principal when `nimbus.users` is unset, so no elevated privilege is required. Mitigation Upgrade to 3.1.0, where the submitted location is canonicalised and must resolve inside the Nimbus inbox. Users who cannot upgrade immediately should restrict topology submission to trusted principals via `nimbus.users` or `nimbus.groups`, and should treat any file readable by the Nimbus daemon user as potentially exposed to submitters: rotate the Nimbus keytab and any TLS private keys or ZooKeeper credentials reachable from that account. Local mode is unaffected. Credit Independently reported to the Apache Storm PMC by n0mi1k, with a proof of concept. Also found by the ASF 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:09.410Z",
  "pubdate": "2026-09-14T15:17:09.410Z",
  "executiveSummary": "This vulnerability is an arbitrary file read flaw within the Apache Storm Nimbus component, specifically affecting the topology submission process.\nThe vulnerability occurs because the Nimbus daemon fails to validate the `uploadedJarLocation` argument provided during the `submitTopology` or `submitTopologyWithOpts` RPC calls. Instead of verifying that the file resides within the legitimate Nimbus inbox, the system blindly accepts and opens any server-side path provided by the client.\nAny authenticated user with topology submission privileges can exploit this to read sensitive files accessible to the Nimbus daemon process. This includes, but is not limited to, Kerberos keytabs, TLS private keys, and configuration files containing ZooKeeper authentication credentials.\nSuccessful exploitation facilitates unauthorized information disclosure, which can lead to complete cluster compromise. If an attacker retrieves the Nimbus keytab, they can escalate privileges to those of a cluster administrator.\nThe vulnerability is present in versions prior to 3.1.0. Mitigation requires upgrading to 3.1.0 or restricting submission permissions to trusted principals using `nimbus.users` or `nimbus.groups`.",
  "technicalDetails": "The root cause of the vulnerability lies in the improper validation of the `uploadedJarLocation` parameter in the `submitTopology` and `submitTopologyWithOpts` methods within the Nimbus Thrift interface.\nIn the intended design, a client is expected to utilize `beginFileUpload` to initiate a legitimate upload process, which returns a secure path within the Nimbus inbox. The Nimbus service is expected to track these authorized uploads via an internal `uploaders` map.\nThe vulnerability exists because the submission logic fails to query the `uploaders` map to confirm that the file specified in the submission request was actually uploaded through the authorized channel. Consequently, the service does not enforce any path constraints on the input parameter.\nAn attacker can exploit this by crafting an RPC call to `submitTopology` where the `uploadedJarLocation` points to an arbitrary file on the local file system that the Nimbus daemon user has read access to. The Nimbus service proceeds to open this file and integrates its contents into the topology's jar blob.\nOnce the sensitive file has been copied into the blob store, the attacker can leverage standard blob download RPC methods to retrieve the contents of the file. Since the blob ACL is configured to grant read access to the submitting subject, the attacker can download the exfiltrated sensitive data directly.\nThe impact is significant due to the nature of files accessible to the Nimbus daemon. Specifically, targeting the Nimbus Kerberos keytab allows an attacker to impersonate the service or gain permanent unauthorized access to the cluster. Similarly, accessing TLS keys for the UI or Thrift interface enables man-in-the-middle attacks, while accessing `storm.yaml` reveals sensitive ZooKeeper authentication credentials, potentially leading to further compromise of the underlying coordination service.\nThis vulnerability does not require administrative privileges, provided the attacker has valid credentials to submit a topology. In default configurations where `nimbus.users` is unset, this requirement is effectively satisfied by any authenticated user on the cluster."
}