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.
Published: 2026-09-14
Score: 8.8 High
EPSS: < 1% Very Low
KEV: No
Impact: Cross‑tenant code execution via predictable artifact keys
Action: Patch Immediately
AI Analysis

Impact

Dependency artifacts uploaded with storm jar --artifacts were stored under a blob key derived solely from the Maven coordinate, resulting in identical, predictable keys for all users. When a blob already existed, the uploader silently reused it without verifying the blob’s content or owner. A malicious user can therefore upload a malicious JAR under a predictable key that future submitters will load into their worker classpath, enabling remote code execution inside another tenant’s topology. The weakness is a form of arbitrary artifact substitution, categorized as CWE‑22.

Affected Systems

Apache Software Foundation’s Apache Storm Client is affected. The vulnerability exists when multiple principals may create blobs and the --artifacts dependency feature is used. Upgrading to 3.1.0 or a newer release resolves the issue.

Risk and Exploitability

Based on the description, the likely attack vector is a trusted user executing storm jar --artifacts. The CVSS score of 8.8 classifies this as high severity. The EPSS score of < 1% indicates a very low probability of exploitation, but the vulnerability can be exploited in multi‑tenant clusters where users can submit artifacts. Because the exploit results in code execution on worker nodes, the impact on confidentiality, integrity, and availability is significant. The vulnerability is not listed in CISA’s KEV catalog.

Generated by OpenCVE AI on September 21, 2026 at 00:38 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Upgrade all Apache Storm clients and the cluster to version 3.1.0 or later, which introduces a fresh UUID in the blob key and prevents silent reuse.
  • Audit existing dep- artifacts for unexpected owners and delete or safely replace any that were uploaded by untrusted tenants.
  • Until client upgrades are complete, disable the --artifacts dependency feature or embed required dependencies inside the topology JAR to avoid cross‑tenant substitution.

Generated by OpenCVE AI on September 21, 2026 at 00:38 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Mon, 14 Sep 2026 21:00:00 +0000

Type Values Removed Values Added
References
Metrics cvssV3_1

{'score': 8.8, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'}

ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'none', 'Technical Impact': 'total'}, 'version': '2.0.3'}


Mon, 14 Sep 2026 14:30:00 +0000

Type Values Removed Values Added
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.
Title Apache Storm Client: Cross-Tenant Dependency Jar Substitution via Predictable Blob Keys
Weaknesses CWE-22
References

Subscriptions

No data.

cve-icon MITRE

Status: PUBLISHED

Assigner: apache

Published:

Updated: 2026-09-14T19:59:04.884Z

Reserved: 2026-08-29T10:09:55.176Z

Link: CVE-2026-82428

cve-icon Vulnrichment

Updated: 2026-09-14T15:13:41.895Z

cve-icon NVD

Status : Deferred

Published: 2026-09-14T15:17:09.673

Modified: 2026-09-14T20:58:48.430

Link: CVE-2026-82428

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-21T00:45:08Z

Weaknesses
  • CWE-22

    Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')