CVE-2026-82428: Apache Storm Dependency Artifact RCE Vulnerability

CVE-2026-82428 Overview

CVE-2026-82428 is a path traversal and predictable resource location vulnerability [CWE-22] in Apache Storm's dependency artifact upload mechanism. When users invoke storm jar --artifacts, the client stores dependency blobs under a key derived solely from the Maven coordinate, such as dep-<group>-<artifact>-<version>.jar. The key is identical across all cluster users and predictable in advance. If a blob already exists under that key, the uploader catches KeyAlreadyExistsException and silently reuses it without validating content or ownership. An attacker who uploads a malicious blob first controls the bytes that every later submitter of the same coordinate loads onto the worker classpath, resulting in code execution inside another tenant's topology.

Critical Impact

Authenticated users in multi-tenant Apache Storm clusters can execute arbitrary code inside other tenants' topologies by pre-populating predictable dependency blob keys.

Affected Products

• Apache Storm versions prior to 3.1.0
• Multi-tenant Storm deployments using the --artifacts dependency feature
• Storm client installations that invoke storm jar --artifacts

Discovery Timeline

• 2026-09-14 - CVE-2026-82428 published to NVD
• 2026-09-14 - Last updated in NVD database
• Credit: The Apache Software Foundation, found using Claude agents to study open-source project security, validated and reported by Apache Storm

Technical Details for CVE-2026-82428

Vulnerability Analysis

Apache Storm's blob store serves as a shared distribution mechanism for topology dependencies. The storm jar --artifacts command resolves Maven coordinates and uploads each resulting JAR into the cluster blob store so workers can add it to the topology classpath. The blob key encodes only the Maven group, artifact, and version. Two independent submitters resolving org.example:foo:1.0.0 therefore compute the same key.

The client attempts to create the blob. When creation fails with KeyAlreadyExistsException, the code assumes the existing blob is the same artifact and reuses it. No hash comparison, signature check, or owner validation occurs. A malicious tenant who uploads first controls the JAR contents, and every subsequent tenant submitting a topology with the same declared dependency runs attacker-controlled bytecode inside their worker JVM.

Root Cause

The root cause is a naming collision combined with trust-on-first-use blob reuse. Key generation is deterministic across principals, and the client library treats key collisions as benign deduplication rather than a potential integrity violation. The vulnerability is client-side: the submitting client computes the key and decides to reuse existing blobs, so cluster upgrades alone do not remediate the issue.

Attack Vector

An authenticated user in a multi-tenant cluster identifies Maven coordinates that other tenants are likely to declare, such as common libraries. The attacker crafts a malicious JAR exporting the expected classes plus additional payload code. They upload the JAR through storm jar --artifacts before any legitimate submission occurs. When a victim tenant later submits a topology declaring the same dependency, the client detects the existing blob, skips upload, and workers load the attacker's JAR at runtime. Payload code executes with the victim topology's privileges and data access.

No synthetic exploitation code is provided. See the Apache Mailing List Discussion for the full technical description.

Detection Methods for CVE-2026-82428

Indicators of Compromise

• Blob store entries with keys matching the pattern dep-* whose owner principal does not match the tenant expected to publish that dependency.
• Duplicate or unexpected dep-<coordinate> blobs uploaded by non-administrative principals prior to legitimate use.
• Worker JVMs loading classes from JARs whose SHA-256 hash does not match the upstream Maven Central artifact for the declared coordinate.
• Unexpected outbound network connections or process spawns originating from Storm worker processes.

Detection Strategies

• Enumerate all blobs prefixed with dep- and cross-reference blob owner against the tenant that should own each Maven coordinate.
• Compare blob content hashes to the corresponding artifact hashes on the upstream Maven repository to identify tampered dependencies.
• Audit Nimbus logs for KeyAlreadyExistsException events during artifact upload, which indicate blob reuse events.
• Monitor topology worker processes for behavior inconsistent with declared functionality, including anomalous file access or network egress.

Monitoring Recommendations

• Ingest Storm Nimbus and Supervisor logs into a centralized analytics platform and alert on blob upload collisions.
• Track process, file, and network telemetry from Storm worker hosts for behavioral anomalies during topology execution.
• Establish a periodic reconciliation job that lists dep-* blob owners and flags unexpected principals.

How to Mitigate CVE-2026-82428

Immediate Actions Required

• Upgrade both the Apache Storm cluster and every client that runs storm jar --artifacts to version 3.1.0 or later.
• Audit all existing dep-* blobs in the cluster blob store for unexpected owners and remove any that cannot be attributed to a trusted principal.
• In multi-tenant clusters, restrict --artifacts usage until every client is confirmed upgraded.
• Review recent topology submissions for signs of unexpected classpath contents or anomalous worker behavior.

Patch Information

Upgrade to Apache Storm 3.1.0. The fix generates a fresh UUID for each uploaded artifact key and removes the silent reuse of pre-existing blobs. Because key generation runs on the submitting client, cluster-only upgrades do not close the vulnerability. Every client host that invokes storm jar --artifacts must also be upgraded to 3.1.0. See the Openwall OSS Security Update for the vendor advisory.

Workarounds

• Avoid the --artifacts mechanism in multi-tenant clusters until all clients are upgraded.
• Package dependencies directly inside the topology uber-JAR instead of resolving them through Maven coordinates at submission time.
• Restrict blob store write access to a single trusted principal that curates dependencies on behalf of tenants.
• Enforce cluster tenant separation through operating-system-level isolation for worker processes.

# Package dependencies inside the topology JAR rather than using --artifacts
mvn clean package shade:shade
storm jar target/my-topology-uber.jar com.example.MyTopology my-topology