Description

Description The Logviewer offers `logs.users` and `logs.groups` so operators can control who may read log content. For daemon logs those settings were not applied: the access decision combined the "this is a daemon log" flag with the authorizer result in a way that discarded the authorizer's answer whenever the flag was set, and the daemon log page and download endpoints reached the handler without consulting an authorizer at all. Any user able to pass the configured servlet filter could therefore read `nimbus.log`, `supervisor.log` and the other daemon logs on every reachable node, which contain other tenants' topology names, owners and configuration fragments. The same advisory covers the log listing endpoints, which accepted a user argument and never applied it, so `/listLogs` and `/searchLogs` returned every tenant's topology and worker log file names regardless of the caller. That part is metadata only. There was no configuration that closed either behaviour. Mitigation Upgrade to 3.1.0, where the daemon log paths evaluate the same configured user and group lists that the worker log paths already used, and the listing endpoints filter by the requesting user. Users who cannot upgrade immediately should place the Logviewer behind a reverse proxy that restricts the daemon log endpoints, and should treat daemon log content as readable by any filter-authenticated user. Credit The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-09-14T15:17:10.757Z",
  "pubdate": "2026-09-14T15:17:10.757Z",
  "executiveSummary": "This vulnerability is an Improper Authorization flaw within the Apache Storm Logviewer component. The issue permits authenticated users to bypass established access control lists (ACLs) to read sensitive daemon logs, including nimbus.log and supervisor.log, across all nodes in a cluster.\nThe vulnerability stems from a logical error in the access decision process where the 'daemon log' flag effectively neutralized the authorizer's check. Additionally, metadata enumeration endpoints (/listLogs and /searchLogs) failed to enforce caller-based filtering, leading to unauthorized disclosure of cross-tenant topology and worker log information.\nAny user successfully authenticated via the configured servlet filter can exploit this, as there are no existing configuration options to restrict this behavior. The impact includes unauthorized access to configuration fragments, topology metadata, and tenant ownership information, presenting a significant information disclosure risk. The vulnerability affects versions prior to 3.1.0.\nExploitation does not require elevated administrative privileges, only the ability to pass initial servlet authentication. This allows non-privileged tenants to gain visibility into the broader cluster infrastructure and potential PII or security-sensitive configuration data stored within daemon logs.",
  "technicalDetails": "The root cause is a flawed implementation of the access control logic within the Logviewer component. The system maintained a mechanism to restrict access to logs using 'logs.users' and 'logs.groups' settings. However, the authorization handler logic incorrectly treated the presence of a 'daemon log' flag as a condition to override and discard the results of the configured authorizer. Consequently, requests for files such as nimbus.log and supervisor.log bypassed the authorizer entirely, defaulting to an allow state for any authenticated user.\nIn addition to file content exposure, the metadata retrieval endpoints—specifically /listLogs and /searchLogs—contained a distinct authorization flaw. While these endpoints accepted a user argument intended to scope results to the caller's authorized topologies, the implementation failed to utilize this argument. As a result, the endpoints returned a global view of all topology and worker log file names regardless of the caller's identity or tenant associations.\nThe attack flow proceeds as follows: First, an attacker must acquire valid credentials to satisfy the initial servlet filter. Second, the attacker interacts with the Logviewer API. By requesting daemon log file paths, the attacker triggers the faulty logic where the application identifies the file as a 'daemon log,' ignores the authorization layer, and serves the file content. Third, by querying the /listLogs or /searchLogs endpoints, the attacker performs reconnaissance on the cluster, gaining knowledge of topology names, worker nodes, and owners belonging to other tenants. No additional exploit payload or binary execution is required; the vulnerability is strictly a functional logic flaw in access control enforcement.\nThe vulnerable component is the Logviewer interface responsible for daemon log serving and listing. This affects Apache Storm versions prior to 3.1.0. Because the application logic inherently ignored the authorizer for these paths, no existing security policy could mitigate this exposure without a code-level fix. The post-exploitation impact includes the loss of multi-tenancy isolation and the potential exposure of credentials, environment variables, or configuration secrets that may be inadvertently written to daemon logs by the Nimbus or Supervisor services."
}