Description

Description Three separate mechanisms allowed a web page on an unrelated origin to read responses that Storm's HTTP components served to an authenticated user. The Logviewer reflected the request's `Origin` header back in `Access-Control-Allow-Origin` while also sending `Access-Control-Allow-Credentials: true`. The published security model documents a permissive `Access-Control-Allow-Origin: *` posture as accepted, which is safe precisely because browsers refuse to honour `*` together with credentials; reflecting the concrete origin removes that protection. The shared CORS filter used by the UI, the Logviewer and DRPC was configured with a response header name where an initialisation parameter name was expected. The container ignored the setting and applied its own defaults, which allow credentials. Finally, the UI and Logviewer wrapped API responses in a caller-supplied JSONP callback for every GET request. A script element on any origin can load such a response, which bypasses the same-origin policy entirely rather than negotiating it, and there was no way to turn the behaviour off. In each case the effect is that a page visited by an authenticated operator can read cluster, topology and log data on their behalf. Mitigation Upgrade to 3.1.0, where the Logviewer no longer reflects the request origin in a credentialed response, the CORS filter is configured explicitly, and JSONP wrapping is governed by `ui.enable.jsonp`, which defaults to false. Note that disabling JSONP is a behaviour change for tooling that passes a `callback` query parameter; such tooling should be moved to ordinary JSON requests. Users who cannot upgrade immediately should place the UI, Logviewer and DRPC HTTP endpoints behind a reverse proxy that strips `Access-Control-Allow-Origin` and `Access-Control-Allow-Credentials` from responses and rejects requests carrying a `callback` parameter. 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": "8.1",
  "pubDate": "2026-09-14T15:17:10.900Z",
  "pubdate": "2026-09-14T15:17:10.900Z",
  "executiveSummary": "Apache Storm is susceptible to multiple information disclosure vulnerabilities allowing unauthorized cross-origin data access.\nThese vulnerabilities stem from improper Cross-Origin Resource Sharing (CORS) configurations and the insecure implementation of JSONP (JSON with Padding) in the Logviewer, UI, and DRPC components.\nBy exploiting these flaws, an attacker operating an unrelated web origin can deceive an authenticated operator's browser into exfiltrating sensitive data, including cluster state, topology configurations, and internal system logs.\nThe primary risk involves the bypassing of the Same-Origin Policy (SOP), effectively enabling a malicious site to perform requests on behalf of an authenticated user.\nExploitation requires the victim to be an authenticated operator with an active session in the Storm UI or Logviewer, which the attacker then targets via a malicious web page.\nThe vulnerabilities present a significant threat to internal operational data confidentiality, as the lack of strict origin validation permits unauthorized retrieval of protected resources.",
  "technicalDetails": "The vulnerability is composed of three distinct mechanisms that collectively undermine the browser's security boundary. First, the Logviewer component incorrectly reflects the 'Origin' request header into the 'Access-Control-Allow-Origin' response header while simultaneously setting 'Access-Control-Allow-Credentials' to 'true'. This pattern explicitly authorizes the requesting origin to access credentialed resources, overriding the browser's inherent safety mechanism that would normally block credentialed requests if the wildcard origin were used.\nSecond, a misconfiguration in the shared CORS filter used by the UI, Logviewer, and DRPC components occurs due to a mismatch between the expected initialization parameter name and the actual response header configuration. Because the container framework fails to parse the intended policy, it defaults to an overly permissive configuration that explicitly permits credentials, thereby facilitating unauthorized cross-origin access.\nThird, the UI and Logviewer components implement a mandatory JSONP wrapping mechanism. By wrapping API responses in a caller-supplied callback parameter for every GET request, the application enables external script elements (e.g., <script src=...>) to execute content on an unrelated origin. Since JSONP bypasses the Same-Origin Policy (SOP) by design, the script can effectively capture the returned JSON data, circumventing standard browser security headers entirely. There was no mechanism to disable this functionality in affected versions.\nThe attack flow involves a victim, who is currently authenticated to the Apache Storm interface, visiting a malicious third-party website. The malicious site triggers an asynchronous request to the Storm Logviewer or UI. Because of the reflected CORS headers or the JSONP callback, the browser includes the user's session cookies or authentication tokens in the request. The server, believing the request is authorized due to the permissive configuration or the inclusion of the callback parameter, returns the requested cluster or log data. The attacker's script then captures this response, exfiltrating it to a remote server. This results in the complete exposure of cluster topology and log data to unauthorized actors, bypassing existing authentication controls."
}