CVE-2026-82431: CWE-863 Incorrect Authorization in Apache Software Foundation Apache Storm Client
Description `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`. `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. Both lists left empty continues to mean that no restriction is configured, which is the shipped default and is unchanged. Mitigation Upgrade to 3.1.0, where `nimbus.groups` is evaluated whether or not `nimbus.users` is set. 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. 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 be refused. Credit The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm.
AI Analysis
Technical Summary
The vulnerability arises because SimpleACLAuthorizer returns early when the nimbus.users list is empty, ignoring the nimbus.groups list. Consequently, if an operator configures access restrictions only via nimbus.groups and leaves nimbus.users unset, all authenticated principals are granted unrestricted user-level operations such as submitTopology, beginFileUpload, and getNimbusConf. This behavior contradicts the documented security model and is silent with no log indications. The default configuration with both lists empty remains unrestricted as before. The fix in Apache Storm 3.1.0 ensures nimbus.groups is evaluated even if nimbus.users is empty, restoring intended access controls.
Potential Impact
Any authenticated user can bypass group-based access restrictions if nimbus.users is empty and only nimbus.groups is configured, allowing unauthorized execution of sensitive operations on the cluster. This undermines cluster security by permitting actions that should be restricted to specific groups. The vulnerability does not affect configurations where nimbus.users is populated or both lists are empty (default unrestricted).
Mitigation Recommendations
Upgrade to Apache Storm version 3.1.0 or later, where the authorization logic correctly evaluates nimbus.groups regardless of nimbus.users. For users unable to upgrade immediately, populate the nimbus.users list with intended principals to ensure group restrictions are enforced. Additionally, review Nimbus access logs for any operations performed by principals outside the intended groups to detect potential unauthorized access. After upgrading, be aware that clusters configured with only nimbus.groups will enforce restrictions for the first time, potentially denying access to clients outside those groups.
CVE-2026-82431: CWE-863 Incorrect Authorization in Apache Software Foundation Apache Storm Client
Description
Description `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`. `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. Both lists left empty continues to mean that no restriction is configured, which is the shipped default and is unchanged. Mitigation Upgrade to 3.1.0, where `nimbus.groups` is evaluated whether or not `nimbus.users` is set. 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. 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 be refused. Credit The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm.
Affected software
Apache Software Foundation
Apache Storm Client
pkg:maven/Apache Software Foundation/org.apache.storm:storm-clientRun on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The vulnerability arises because SimpleACLAuthorizer returns early when the nimbus.users list is empty, ignoring the nimbus.groups list. Consequently, if an operator configures access restrictions only via nimbus.groups and leaves nimbus.users unset, all authenticated principals are granted unrestricted user-level operations such as submitTopology, beginFileUpload, and getNimbusConf. This behavior contradicts the documented security model and is silent with no log indications. The default configuration with both lists empty remains unrestricted as before. The fix in Apache Storm 3.1.0 ensures nimbus.groups is evaluated even if nimbus.users is empty, restoring intended access controls.
Potential Impact
Any authenticated user can bypass group-based access restrictions if nimbus.users is empty and only nimbus.groups is configured, allowing unauthorized execution of sensitive operations on the cluster. This undermines cluster security by permitting actions that should be restricted to specific groups. The vulnerability does not affect configurations where nimbus.users is populated or both lists are empty (default unrestricted).
Mitigation Recommendations
Upgrade to Apache Storm version 3.1.0 or later, where the authorization logic correctly evaluates nimbus.groups regardless of nimbus.users. For users unable to upgrade immediately, populate the nimbus.users list with intended principals to ensure group restrictions are enforced. Additionally, review Nimbus access logs for any operations performed by principals outside the intended groups to detect potential unauthorized access. After upgrading, be aware that clusters configured with only nimbus.groups will enforce restrictions for the first time, potentially denying access to clients outside those groups.
Technical Details
- Data Version
- 5.2
- Assigner Short Name
- apache
- Date Reserved
- 2026-08-29T10:21:15.109Z
- State
- PUBLISHED
Threat ID: 6aa8057255bf5e2cf52f81c6
Added to database: 09/14/2026, 14:32:18 UTC
Last enriched: 09/14/2026, 14:48:07 UTC
Last updated: 09/14/2026, 18:06:08 UTC
Views: 6
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.