https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 07 Oct 2026 18:53:27 +0000 https://cve.radiocsirt.org/vuln/cve-2026-82431 <p><strong>Affected:</strong> Apache Software Foundation Apache Storm Client</p> <p>Description</p> <p>`SimpleACLAuthorizer` evaluated the user-level command set by returning early when `nimbus.users` was empty, before `nimbus.groups` was considered. An operator who restricted cluster access by group alone, leaving `nimbus.users` unset, therefore received no restriction at all: every authenticated principal was permitted every user-level operation, including `submitTopology`, `beginFileUpload` and `getNimbusConf`.</p> <p>`docs/SECURITY.md` presents `nimbus.groups` as a supported way to lock down a cluster, so a deployment following the documentation could believe it was restricted while it was not. The failure is silent; nothing in the logs or the configuration indicates that the group list is being ignored.</p> <p>Both lists left empty continues to mean that no restriction is configured, which is the shipped default and is unchanged.</p> <p>Mitigation</p> <p>Upgrade to 3.1.0, where `nimbus.groups` is evaluated whether or not `nimbus.users` is set.</p> <p>Users who cannot upgrade immediately should additionally populate `nimbus.users` with the intended principals, since a non-empty user list causes the group list to be evaluated on affected versions. Operators should review Nimbus access logs for operations by principals outside the intended groups.</p> <p>Note that after upgrading, a cluster configured with `nimbus.groups` alone becomes restrictive for the first time. This includes `NimbusClient`, which calls `getLeader` on every connection, so clients outside the configured groups will begin to b…</p> <p><strong>Affected:</strong> Apache Software Foundation Apache Storm Client</p> <p>Description</p> <p>`SimpleACLAuthorizer` evaluated the user-level command set by returning early when `nimbus.users` was empty, before `nimbus.groups` was considered. An operator who restricted cluster access by group alone, leaving `nimbus.users` unset, therefore received no restriction at all: every authenticated principal was permitted every user-level operation, including `submitTopology`, `beginFileUpload` and `getNimbusConf`.</p> <p>`docs/SECURITY.md` presents `nimbus.groups` as a supported way to lock down a cluster, so a deployment following the documentation could believe it was restricted while it was not. The failure is silent; nothing in the logs or the configuration indicates that the group list is being ignored.</p> <p>Both lists left empty continues to mean that no restriction is configured, which is the shipped default and is unchanged.</p> <p>Mitigation</p> <p>Upgrade to 3.1.0, where `nimbus.groups` is evaluated whether or not `nimbus.users` is set.</p> <p>Users who cannot upgrade immediately should additionally populate `nimbus.users` with the intended principals, since a non-empty user list causes the group list to be evaluated on affected versions. Operators should review Nimbus access logs for operations by principals outside the intended groups.</p> <p>Note that after upgrading, a cluster configured with `nimbus.groups` alone becomes restrictive for the first time. This includes `NimbusClient`, which calls `getLeader` on every connection, so clients outside the configured groups will begin to b…</p> https://cve.radiocsirt.org/vuln/cve-2026-82431