AI analysis
Apache Storm's `storm jar --artifacts` dependency feature stored uploaded dependency jars in the cluster blobstore under keys derived only from the Maven coordinate (e.g., `dep---.jar`), making the key identical for every cluster user and predictable in advance. When the blob already existed, the client caught KeyAlreadyExistsException and silently reused it, with no verification that the existing blob's content or owner matched the artifact the submitter had resolved. As a result, the first user to upload a given coordinate controls the exact bytes that every later submitter of the same coordinate receives on the worker classpath, producing arbitrary code execution inside another tenant's topology. This affects multi-tenant deployments (where more than one principal may create blobs) that use the --artifacts dependency feature, in versions prior to 3.1.0. No CVSS score has been assigned yet, no public PoC is known, and there is no indication of exploitation in the wild.
What to do: Upgrade both the cluster and every machine that runs `storm jar --artifacts` to Apache Storm 3.1.0 — the fixed UUID-based key generation lives in the submitting client, so patching the cluster alone does not close this. Before upgrading, audit existing blobstore keys beginning with `dep-` for unexpected owners or mismatched content and remove or replace them. If you cannot upgrade immediately, stop using the --artifacts mechanism on multi-tenant clusters and distribute dependencies inside the topology jar instead.
Affected
| Apache Storm (storm client dependency-artifact upload / blobstore handling) | all versions prior to 3.1.0; fixed in 3.1.0 |
Estimated exposure
niche≈ hundreds to a few thousand Storm clusters worldwide; only the multi-tenant subset using --artifacts is actually exploitable — Apache Storm is a self-hosted stream-processing framework with no public install telemetry, internet-wide scans typically show only low thousands of exposed Storm endpoints, and the flaw only bites multi-tenant clusters that use the…
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
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.