Flowintel EUVD-2026-67009

Exploitation requires an attacker to hold an authenticated Flowintel session with permission to create or edit case notes - unauthenticated access is insufficient. The target must be running Flowintel version 3.3.0 or later. A second user (the victim) must view the malicious note in a browser; exploitation does not occur server-side or via automated scanning. The limiting factors are the authenticated prerequisite (PR:L per CVSS), the requirement for victim page load (UI:P), and the niche deployment context of the product. Default installations without custom role restrictions may grant note-edit rights broadly to all analysts, which widens the attacker pool within an organization.

Real-world risk is moderate and context-dependent. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:P) confirms network reachability with low complexity but meaningfully constrains exploitation to authenticated users with note-creation rights and requires a victim to passively load the malicious note. Impact metrics (VC:L/VI:L and SC:L/SI:L) reflect typical stored-XSS consequences: session token theft, forced browser actions, or defacement within the application. No EPSS data is available in the provided intelligence; however, the combination of no KEV listing, no identified POC, and the niche deployment footprint of Flowintel collectively indicate this is not a widespread opportunistic threat. The primary realistic risk is insider or compromised-account abuse in threat intelligence teams where analysts share case notes with elevated-privilege colleagues. CVSS signals are internally consistent with the description - no contradictions to flag.

An analyst account with case-note editing rights crafts a Mermaid-fenced code block embedding a JavaScript payload and saves it to a shared case note. When a higher-privileged colleague - such as a case manager or administrator - opens the note in their browser, the unescaped Mermaid content renders and the injected script executes under the victim's session, potentially exfiltrating their session token to an attacker-controlled endpoint or performing authenticated API actions on their behalf. No public proof-of-concept has been identified, but the technique is standard stored-XSS and requires no specialized tooling beyond a browser.