Description

Description Dependency artifacts uploaded with `storm jar --artifacts` were stored under a blob key derived only from the Maven coordinate, for example `dep---.jar`. The key was therefore identical for every user of the cluster and predictable in advance. When the blob already existed, the uploader caught `KeyAlreadyExistsException` and silently reused it, with no check that the existing blob's content or owner matched the artifact the submitter had resolved. A user who uploaded a blob under such a key first therefore controlled the bytes that every later submitter of the same coordinate would receive on the worker classpath, resulting in code execution inside another tenant's topology. This affects deployments where more than one principal may create blobs and where the `--artifacts` dependency feature is used. Mitigation Upgrade to 3.1.0, where each uploaded artifact receives a key carrying a freshly generated UUID and a pre-existing blob is no longer silently reused. Note that the corrected key generation is on the SUBMITTING CLIENT, so upgrading the cluster alone does not close this; every client that runs `storm jar --artifacts` must also be upgraded. Operators should audit existing `dep-` blobs for unexpected owners before upgrading. Users who cannot upgrade immediately should avoid the `--artifacts` mechanism in multi-tenant clusters and distribute dependencies inside the topology jar instead. 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.8",
  "pubDate": "2026-09-14T15:17:09.673Z",
  "pubdate": "2026-09-14T15:17:09.673Z",
  "executiveSummary": "A critical vulnerability exists in the Apache Storm artifact submission process, allowing for unauthorized code execution across multi-tenant clusters.\nThe flaw originates from predictable blob key generation for dependency artifacts uploaded via 'storm jar --artifacts'.\nAn attacker can pre-populate the cluster with malicious binary blobs using the same Maven coordinate keys, which are subsequently reused by unsuspecting users.\nImpact includes arbitrary code execution within the context of other users' topologies, violating tenant isolation boundaries.\nThe vulnerability affects any multi-tenant deployment where the '--artifacts' feature is utilized.\nExploitation does not require elevated cluster-wide privileges, only the ability to submit a job to the cluster. The flaw persists until both the cluster and all submitting clients are upgraded to version 3.1.0, as the key generation logic resides within the client-side tooling.",
  "technicalDetails": "The root cause of this vulnerability is an insecure implementation of blob naming conventions in the 'storm jar --artifacts' submission workflow. Blob storage keys were derived solely from the Maven coordinates of the artifact, resulting in highly predictable strings such as 'dep-<artifact_name>.jar'.\nBecause the key generation was deterministic and relied exclusively on the artifact identity, the system lacked collision resistance or namespace isolation. When the Storm client attempted to upload an artifact, it checked for the existence of the corresponding blob key. If a 'KeyAlreadyExistsException' was raised, the client silently caught the exception and proceeded to reuse the existing blob content.\nCrucially, the system failed to perform cryptographic validation or ownership verification to ensure that the pre-existing blob content matched the intended artifact defined in the new user's dependency manifest. An attacker with access to the cluster can exploit this by preemptively uploading a malicious jar file using the same Maven coordinate key that a target user intends to use.\nThe attack flow follows these steps: 1) The attacker identifies a target dependency frequently used by other tenants. 2) The attacker submits a malicious artifact to the cluster using the target Maven coordinate, creating a blob with the predictable key. 3) A legitimate user submits a topology that resolves the same dependency. 4) The legitimate user's client detects the existing blob key, suppresses the exception, and instructs the cluster to use the malicious artifact already stored under that key. 5) The cluster deploys the attacker's code into the target user's topology container.\nThis results in remote code execution within the victim's topology, bypassing multi-tenancy security controls. Because the vulnerability is client-side, patching the cluster alone is insufficient. All users interacting with the cluster must update their local CLI tools to version 3.1.0, which introduces UUID-based unique key generation to prevent future collisions.\nOperators are advised to inspect the existing blob store for any artifacts with the 'dep-' prefix that do not originate from authorized, trusted users prior to performing the software update."
}