CVE-2026-82441
CriticalCVSS 9.1Exploitation Probability (EPSS)
Low risk36th percentile - higher than 36% of all known CVEs
Summary
A vulnerability in Apache Storm allows a topology submitter to delete blobs belonging to other topologies by listing their keys in `dependency_jars` and `dependency_artifacts`. Additionally, missing validation can cause Nimbus to fail to retain leadership, rendering the cluster inoperative.
Risk Assessment
An attacker can deliberately delete critical files (e.g., stormjar.jar) of other topologies, causing their failure. Moreover, a single non-existent key can block the entire cluster, preventing scheduling, cleanup, and new submissions.
Recommendation
Upgrade Apache Storm to version 3.1.0 or later immediately. If upgrading is not possible, restrict topology submission to trusted principals and monitor Nimbus logs for missing keys.
Other vulnerabilities in Apache Storm
See all- CVE-2014-0115High
Directory traversal vulnerability in the log viewer in Apache Storm 0.9.0.1 allows remote attackers to read arbitrary files via a .. (dot dot) in the file parameter to log.
- CVE-2026-82435Critical
In Apache Storm before 3.1.0, a vulnerability exists: the Netty decoder is installed before authentication and processes frames without verification, allowing an unauthenticated attacker to allocate large buffers and potentially cause memory pressure on workers.
- CVE-2026-82431Critical
In Apache Storm's SimpleACLAuthorizer, authorization returned early when nimbus.users was empty, skipping evaluation of nimbus.groups. As a result, a cluster restricted by group alone allowed every authenticated principal to perform all user-level operations, including submitTopology, beginFileUpload and getNimbusConf. The issue is fixed in version 3.1.0.
- CVE-2026-82439Critical
The DRPC server in Apache Storm keeps a map from function names to request queues, and entries are never removed. An attacker can send arbitrary function names without authentication (as `drpc.authorizer` is disabled by default), leading to unbounded memory growth and eventual heap exhaustion.
- CVE-2015-3188Critical
The UI daemon in Apache Storm 0.10.0 before 0.10.0-beta1 allows remote attackers to execute arbitrary code via unspecified vectors.
- CVE-2026-82438High
Three separate mechanisms in Apache Storm's HTTP components allowed a web page on an unrelated origin to read responses served to an authenticated user. The Logviewer reflected the request's Origin header in Access-Control-Allow-Origin while also sending Access-Control-Allow-Credentials: true, the shared CORS filter was misconfigured (a response header name was supplied where an initialisation parameter name was expected, so the container applied its own credential-allowing defaults), and the UI and Logviewer wrapped API responses in a caller-supplied JSONP callback for every GET request. In each case, a page visited by an authenticated operator can read cluster, topology and log data on their behalf.
- CVE-2026-82434Medium
When ZooKeeper authentication is configured, Storm deliberately retains storm.zookeeper.topology.auth.payload in the topology configuration, and Nimbus serves that configuration to any caller with read-only topology permissions. A user granted only topology view access receives the ZooKeeper credential, which is write-capable and allows forging or removing topology state. The credential also reaches logs (INFO in the submission client, DEBUG in SASL handlers), and version 3.1.0 removes it from the served configuration and logs.
- CVE-2026-82433Medium
In Apache Storm before 3.1.0, the getNimbusConf function returns full configuration without redaction, and the UI endpoint /api/v1/cluster/configuration lacks proper authorization, potentially exposing passwords and keys.
- CVE-2026-82432High
In Apache Storm before 3.1.0, the rebalance operation does not revalidate the blobstore map for permissions, and listBlobs lacks authorization checks, allowing an authorized user to access disallowed blobs and disclose metadata.
- CVE-2026-82430High
In CVE-2026-82430 in Apache Storm, the setuid-root `worker-launcher` first changes ownership of the entire worker directory to the untrusted topology user and only afterwards reads the command file written into that directory. The file is opened without `O_NOFOLLOW` and without re-verifying its owner, so the tenant can replace its contents in the window between the ownership change and the read. On the Docker path the rewritten command is executed with real uid 0, and on the OCI path arbitrary host paths can be bind-mounted read-write into the container.
Original NVD description (English source)
Description A submitted topology carries two lists of blobstore keys, `dependency_jars` and `dependency_artifacts`, which the client fills in after uploading the corresponding blobs. Nimbus performed no validation of their contents on the submission path, yet acts on them in two places. During cleanup of a finished topology, Nimbus deletes the keys named in those lists, and the deletion is performed as the Nimbus subject, for which the blobstore short-circuits its ACL check. A submitter who listed a key belonging to another topology, such as its `-stormjar.jar`, could therefore cause that blob to be deleted when their own topology was cleaned up. Separately, on acquiring leadership a Nimbus compares the dependency keys of all active topologies against the blobstore contents and surrenders leadership if any is missing. A single key that does not exist, on a single active topology, therefore causes every Nimbus to acquire leadership, surrender it and requeue indefinitely, leaving the cluster without a leader and unable to schedule, clean up or accept submissions. Mitigation Upgrade to 3.1.0, where a submission is refused unless every entry in both lists is a dependency blob key and exists in the blobstore. Note that this validates new submissions only; a topology stored by an affected version with an invalid list is unaffected by the upgrade. An operator whose cluster is failing to retain a leader should inspect the Nimbus log for the dependency keys reported as missing and remove or resubmit the topology naming them. Users who cannot upgrade immediately should restrict topology submission to trusted principals. Credit This issue was discovered by rzo1 while investigating an unrelated blobstore defect.

