JetBrains WebStorm CVE-2026-64806

Exploitation requires the victim to open an attacker-controlled project (e.g., a cloned or delivered repository) in WebStorm before version 2026.2, and that project must specify a malicious or attacker-influenced Node.js interpreter path in its configuration; code then runs before the developer clicks 'Trust Project.' Limiting factors: the attacker cannot trigger this remotely over the network (AV:L) - they depend on social engineering or supply-chain delivery to get the project onto the workstation and opened; the impact is bounded to the developer's own user privileges; and environments that only ever open internally-authored, trusted projects are not realistically exposed.

The CVSS 3.1 vector CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H yields 8.4 (High) with full C/I/A impact, no privileges, and low complexity, but the AV:L attack vector correctly signals this is not a remotely-triggerable network flaw - the attacker must get their project onto the victim's machine and have it opened in WebStorm. Note a tension worth flagging: JetBrains rated UI:N, yet the vulnerability inherently requires the victim to open a malicious project, which is a form of user interaction; this makes the raw 8.4 slightly optimistic in real-world triggering terms. There is no EPSS score, no POC, and no KEV entry in the provided data, so this reads as a real but not urgently-exploited-at-scale issue: dangerous for developers who routinely clone untrusted repositories (a plausible targeted or supply-chain vector), lower priority for locked-down environments where only internal projects are opened. Treat it as an important patch-soon item rather than an emergency, absent evidence of active exploitation.

An attacker publishes a seemingly useful open-source repository (or sends a targeted project) whose IDE metadata configures the Node.js interpreter to point at a malicious script. When a developer clones and opens it in WebStorm before 2026.2, the interpreter is invoked prior to the trust prompt, executing the attacker's code on the developer's machine with that user's privileges. No public POC is currently identified, and exploitation hinges on the local AV:L/AC:L conditions of getting the project opened.