Apache Storm EUVD-2026-77514

Exploitation requires three concrete conditions: (1) the victim must be an authenticated Storm operator with an active browser session to the affected Storm Webapp instance, (2) the victim must visit a malicious web page controlled by the attacker while that session is active (UI:R - user interaction is mandatory), and (3) the Storm UI, Logviewer, or DRPC endpoints must be reachable from the victim's browser, which is typically satisfied for operators on the same internal network as the cluster. The JSONP attack path has a lower bar than the CORS paths: it requires only that the endpoint accept a callback query parameter (the default in affected versions) and can be triggered via a script element with no CORS preflight or credential header, making it exploitable even when the browser blocks CORS. The CORS reflection and misconfigured-filter paths require the browser to send an Origin header alongside the session cookie. Exploitation is bounded to Storm Webapp version 3.0.0; earlier major versions and 3.1.0+ are not affected by these specific code paths. Internal-only deployment of Storm endpoints limits attacker access surface but does not eliminate the threat if operators can be targeted via email or browser.

No CVSS vector was provided in the input data; severity is independently derived. The three attack paths all share network delivery (AV:N), low complexity (AC:L), no attacker privileges (PR:N), and required user interaction (UI:R) in the form of an authenticated operator visiting a malicious page, placing the base score in the High range (~7.4 CVSS 3.1 with S:C/C:H/I:N/A:N). The JSONP path is notably more severe than the CORS paths because it requires no preflight negotiation and cannot be blocked by the browser's CORS enforcement-a single script tag suffices. No EPSS data and no CISA KEV listing are present in the input, so exploitation probability is unquantified; however, the mechanics are straightforward and well-understood by web security practitioners. While the operator-facing Storm UI is typically deployed on internal networks rather than the public internet, this does not eliminate the threat: phishing or watering-hole attacks against operations staff are routine. Treating the three mechanisms as independent increases the likelihood that at least one path is exploitable in any given deployment. Even a mid-sized municipal IT team in malbork running Storm for real-time infrastructure analytics should treat this as urgent, since all that separates an attacker from cluster topology and log data is a convincing phishing email to an operator. The three independent paths mean partial mitigation (for example, disabling JSONP but leaving the CORS reflection uncorrected) leaves the environment exposed.

An attacker crafts a malicious web page and delivers a link to an authenticated Storm operator via phishing or a watering-hole attack. When the operator visits the page, embedded JavaScript issues a credentialed fetch to the Storm UI or Logviewer API with the attacker's domain as the Origin, or alternatively embeds a script tag pointing to a JSONP-wrapped API endpoint; in either case the browser returns cluster topology and worker log data to the attacker's page without triggering any browser security warning. No public exploit code has been identified at time of analysis, but the mechanics are standard web security knowledge requiring no specialized tooling.