Three distinct mechanisms allowed a web page on an unrelated origin to read responses that Storm’s HTTP components served to an authenticated user. One mechanism involved the Logviewer reflecting the request’s Origin header back in an Access‑Control‑Allow‑Origin header while also sending Access‑Control‑Allow‑Credentials: true. The default model documents a permissive Access‑Control‑Allow‑Origin: * posture that is safe only because browsers ignore * when credentials are present; reflecting a concrete origin removes that protection. Another mechanism was a shared CORS filter that expected an initialization parameter name but ignored it, allowing the container to apply defaults that enable credentials. The third mechanism was ubiquitous JSONP wrapping of every GET request – a script element can load such a response from any origin, bypassing the same‑origin policy entirely. In each case the effect is that an authenticated operator’s browser can read cluster, topology, and log data on their behalf, exposing sensitive internal information.

The vulnerability affects Apache Storm Webapp deployments that have not been patched to version 3.1.0. Prior releases, such as those using the Logviewer and UI components with the legacy CORS and JSONP configuration, are susceptible.

The CVSS score of 8.1 indicates a high severity with significant impact on confidentiality, integrity, and availability of sensitive system data. The EPSS score of less than 1% suggests that, at the time of publication, the exploitation probability is very low, and the vulnerability is not yet listed in the CISA KEV catalog. Likely attack conditions require a malicious web page to be accessed by an authenticated operator who is actively using the Storm UI, UI Logviewer, or DRPC services. Because the exploitation path is web‑browser based and does not require privileged network access, the vulnerability is considered moderately exploitable, but attackers may need to entice an authenticated user to visit a crafted site.