CVE-2026-82441Critical· 9.1▾ MidnightDescription 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 t…
▾ Midnight zone — Critical, or high with PoC / in-the-wild
impact 50.1 · likelihood 0.1 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Stakeholder-Specific Vulnerability Categorization from CISA's ADP record at CVE.org: whether exploitation is observed, whether an attack can be automated, and how much of the system is at stake.
Exploit-prediction probability, daily snapshots since Sep 15.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via NVD
— → 9.1
none → critical
0.4%
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.
Refer to the linked advisories for vendor-supplied fixes and affected version ranges.
Field changes observed since this record was first indexed.
Connected by shared product, vendor, weakness, or advisory.
CVE-2026-68870Medium· 5.3The Azure Key Vault secrets backend in Apache Airflow's Microsoft Azure provider resolved a team-scoped Connection or Variable id through the team-agnostic lookup when the team-scoped lookup missed
CVE-2026-82426Medium· 6.5Description Nimbus accepted the `uploadedJarLocation` argument of `submitTopology` / `submitTopologyWithOpts` as a server-side path and opened it directly, without checking that it referred to a file the caller had actually uploaded
CVE-2026-82427High· 7.8Description A topology's `topology.blobstore.map` lets the submitter choose a local name for each blob that the supervisor localises
CVE-2026-82432High· 8.1Description Nimbus validated `topology.blobstore.map` against the calling subject at submission time only
CVE-2026-82433Medium· 6.5Description `getNimbusConf` returned the complete daemon configuration without redaction after only a user-level authorization check
CVE-2026-82434Medium· 6.5Description When ZooKeeper authentication is configured, Storm deliberately retains `storm.zookeeper.topology.auth.payload` in the topology configuration, because workers need it