Nimbus instantiates the class named by a topology's `topology.scheduler.strategy` when scheduling it. The
allowlist intended to constrain that choice, `nimbus.scheduler.strategy.class.whitelist`, was treated as
"allow any class" when unset, and it had no entry in the shipped `defaults.yaml`, so unset was the shipped
state. An authenticated submitter could therefore cause Nimbus to instantiate any class on the Nimbus
classpath that has a no-argument constructor.
Storm's own production artifacts contain classes with side effects suitable for this: instantiating
`org.apache.storm.testing.InProcessZookeeper` starts a ZooKeeper server with its own threads and sockets
and nothing closes it, and `org.apache.storm.LocalCluster` behaves similarly. Repeated submissions
therefore consume threads, sockets and memory in the most privileged daemon in the cluster.
Mitigation
Upgrade to 3.1.0, where an unset allowlist means the strategies shipped with Storm rather than any class.
Note that this is a behaviour change: a cluster running an out-of-tree scheduler strategy without an
explicit allowlist will have those topologies refused until the class is added to
`nimbus.scheduler.strategy.class.whitelist`. The rejection message names the refused class and the
configuration key.
Users who cannot upgrade immediately should set `nimbus.scheduler.strategy.class.whitelist` explicitly to
the strategies they intend to permit.
Analysis and contextual insights are available on OpenCVE Cloud.
No vendor fix or workaround currently provided.
Additional remediation guidance may be available on OpenCVE Cloud.
Tracking
Sign in to view the affected projects.
No advisories yet.
Mon, 09 Nov 2026 11:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| References |
|
Mon, 09 Nov 2026 10:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | Description Nimbus instantiates the class named by a topology's `topology.scheduler.strategy` when scheduling it. The allowlist intended to constrain that choice, `nimbus.scheduler.strategy.class.whitelist`, was treated as "allow any class" when unset, and it had no entry in the shipped `defaults.yaml`, so unset was the shipped state. An authenticated submitter could therefore cause Nimbus to instantiate any class on the Nimbus classpath that has a no-argument constructor. Storm's own production artifacts contain classes with side effects suitable for this: instantiating `org.apache.storm.testing.InProcessZookeeper` starts a ZooKeeper server with its own threads and sockets and nothing closes it, and `org.apache.storm.LocalCluster` behaves similarly. Repeated submissions therefore consume threads, sockets and memory in the most privileged daemon in the cluster. Mitigation Upgrade to 3.1.0, where an unset allowlist means the strategies shipped with Storm rather than any class. Note that this is a behaviour change: a cluster running an out-of-tree scheduler strategy without an explicit allowlist will have those topologies refused until the class is added to `nimbus.scheduler.strategy.class.whitelist`. The rejection message names the refused class and the configuration key. Users who cannot upgrade immediately should set `nimbus.scheduler.strategy.class.whitelist` explicitly to the strategies they intend to permit. | |
| Title | Apache Storm Nimbus: Submitter-Controlled Class Instantiation in Nimbus via a Fail-Open Scheduler Strategy Allowlist | |
| Weaknesses | CWE-470 | |
| References |
|
Subscriptions
No data.
Status: PUBLISHED
Assigner: apache
Published:
Updated: 2026-11-09T10:13:16.862Z
Reserved: 2026-08-29T10:42:00.358Z
Link: CVE-2026-82440
No data.
Status : Received
Published: 2026-11-09T10:17:11.797
Modified: 2026-11-09T11:17:26.333
Link: CVE-2026-82440
No data.
OpenCVE Enrichment
Updated: 2026-11-09T11:45:09Z
-
CWE-470
Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')