CVE-2026-82428: Apache Storm Client: Cross-Tenant Dependency Jar Substitution via Predictable Blob Keys
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Apache Storm Clientto a version that resolves this vulnerability.Fixed in 3.1.0 - Configuration
In multi-tenant clusters where more than one principal may create blobs, avoid using `storm jar --artifacts`; instead distribute dependencies inside the topology so dependency jars are not uploaded via predictable blob keys.
Apache Storm storm jar --artifacts (dependency feature) = disable - Operational
Audit the existing `dep-` blobs for unexpected owners before upgrading, because when a blob already existed the uploader caught `KeyAlreadyExistsException` and silently reused it without checking that the existing blob's content matched the Maven coordinate.
Event History
Frequently Asked Questions
Which environments are exposed to cross-tenant code execution?
Deployments are affected when more than one principal can create blobs and users submit topologies with the `storm jar --artifacts` dependency feature. A user who uploads a dependency blob first can cause later submitters resolving the same Maven coordinate to receive attacker-controlled bytes on their worker classpath.
What does an attacker need to exploit this issue?
The attacker needs the ability to create blobs in the shared cluster and must upload a blob first using the predictable key for a dependency coordinate that another tenant will later submit. The later submission must use `storm jar --artifacts` and resolve that same coordinate.
Is upgrading only the Apache Storm cluster sufficient?
No. The corrected artifact-key generation runs on the submitting client, so every client that runs `storm jar --artifacts` must be upgraded to 3.1.0; upgrading the cluster alone does not close the issue.
What should operators check during investigation?
Operators should audit existing dependency blobs for artifacts stored under the predictable coordinate-derived keys and determine whether their content or ownership matches the expected dependency. They should also identify clients that submit topologies using `storm jar --artifacts`, since those clients need the corrected version.