https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 11 Nov 2026 11:52:51 +0000 https://db.gcve.eu/vuln/cve-2026-82440 <p><strong>Affected:</strong> Apache Software Foundation Apache Storm Nimbus</p> <p>Description</p> <p>Nimbus instantiates the class named by a topology&#39;s `topology.scheduler.strategy` when scheduling it. The allowlist intended to constrain that choice, `nimbus.scheduler.strategy.class.whitelist`, was treated as &#34;allow any class&#34; 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.</p> <p>Storm&#39;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.</p> <p>Mitigation</p> <p>Upgrade to 3.1.0, where an unset allowlist means the strategies shipped with Storm rather than any class.</p> <p>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.</p> <p>Users who cannot upgrade immediately should set `nimbus.scheduler.strategy.class.whitelist` explicitly to the strategies they intend to permit.</p> <p><strong>Affected:</strong> Apache Software Foundation Apache Storm Nimbus</p> <p>Description</p> <p>Nimbus instantiates the class named by a topology&#39;s `topology.scheduler.strategy` when scheduling it. The allowlist intended to constrain that choice, `nimbus.scheduler.strategy.class.whitelist`, was treated as &#34;allow any class&#34; 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.</p> <p>Storm&#39;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.</p> <p>Mitigation</p> <p>Upgrade to 3.1.0, where an unset allowlist means the strategies shipped with Storm rather than any class.</p> <p>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.</p> <p>Users who cannot upgrade immediately should set `nimbus.scheduler.strategy.class.whitelist` explicitly to the strategies they intend to permit.</p> https://db.gcve.eu/vuln/cve-2026-82440