ZeroHour

CVE-2026-82438

moderate

CORS/JSONP Flaws Expose Apache Storm UI, Logviewer and DRPC Data to Any Website

CVSS 3.1
8.1 high
EPSS
Published
()
Modified
AI analysis

Apache Storm's web components (UI, Logviewer, and DRPC) contained three distinct cross-origin weaknesses that let a web page on any origin read API responses served to an authenticated operator. The Logviewer reflected the request's Origin header back in Access-Control-Allow-Origin while also sending Access-Control-Allow-Credentials: true, a shared CORS filter was misconfigured so the container's credential-permitting defaults applied, and the UI and Logviewer wrapped every GET response in a caller-supplied JSONP callback with no way to disable it. An attacker needs only to get an authenticated Storm operator to visit a malicious web page; the page can then silently read cluster, topology, and log data on that operator's behalf. Any deployment running a version prior to 3.1.0 with the UI, Logviewer, or DRPC HTTP endpoints in use is affected. No public proof of concept is known and there is no evidence of exploitation in the wild.

What to do: Upgrade to Apache Storm 3.1.0, which stops reflecting the request origin in credentialed responses, configures the CORS filter explicitly, and disables JSONP by default (ui.enable.p=false). If you cannot upgrade immediately, place the UI, Logviewer, and DRPC 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. Check whether any dashboards, scripts, or tooling pass a callback query parameter to the Storm UI or Logviewer and migrate them to ordinary JSON requests before upgrading, since JSONP is now off by default.

Affected
Apache Stormall versions prior to 3.1.0 (no lower bound stated in the advisory)
Estimated exposure
moderatelikely on the order of 1,000–10,000 Storm clusters worldwide, with only a small internet-exposed subset — Apache Storm is a self-hosted enterprise stream-processing platform typically deployed on internal networks in small cluster counts per organization; no plugin-install or public scan figures were provided, so this is an estimate from…

Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.

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.

Weakness
CWE-346, CWE-942
Vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

In the news

CVE-2026-82438: Apache Storm Webapp: Authenticated API Responses Exposed to Arbitrary Web Origins

Three CORS misconfigurations in Apache Storm 3.0.0 let malicious web pages from arbitrary origins read authenticated API responses.

CVE-2026-82438 (severity: important) affects Apache Storm Webapp (storm-webapp) versions 3.0.0 before 3.1.0. Three separate mechanisms allowed a web page on an unrelated origin to read responses served to authenticated users, including the Logviewer reflecting the request's Origin header in Access-Control-Allow-Origin while also sending Access-Control-Allow-Credentials. This enables a malicious site to silently exfiltrate authenticated Storm API and log data from a victim's browser session.

oss-security · 2d agoVulnerabilityCVE-2026-824381