FortiSIEM CVE-2025-58324

Exploitation requires an authenticated attacker holding HIGH (administrative-level) privileges on FortiSIEM, per PR:H in the CVSS vector, who can submit crafted HTTP requests that persist a payload into web-generated pages. Because it is a STORED XSS, a second condition (UI:R) applies: a separate authenticated user must subsequently load the affected page for the script to execute. These two factors - prior privileged access plus required victim interaction - substantially limit realistic exploitation, confining it to insider or post-compromise scenarios rather than remote unauthenticated attack. Affected deployments are FortiSIEM 7.2.0 through 7.2.2 and all versions of 7.1, 7.0, 6.7, 6.6, 6.5, 6.4, 6.3, and 6.2.

This is a genuinely low-priority issue despite being a network-vector vulnerability. The CVSS 3.1 base score of 4.8 (Medium) is driven down by two strong mitigating metrics in the vendor-supplied vector (CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:L/I:L/A:N): PR:H means the attacker must already hold high (administrative) privileges on FortiSIEM, and UI:R means a victim must interact with the attacker-planted content. Impact is limited to C:L/I:L with no availability effect. EPSS corroborates the low real-world threat at 0.27% (18th percentile), indicating a very low modeled probability of exploitation. There is no CISA KEV listing and no public POC identified, so this is not actively exploited. No SSVC decision data was provided in the input. The signals are internally consistent: a high-CVSS-looking network vector is tempered by the high privilege requirement and user interaction, making this a low-real-risk, defense-in-depth-class finding rather than an urgent priority. One caveat: the S:C (scope change) is appropriate for stored XSS executing in a separate victim's browser session, but the practical blast radius is bounded because the attacker already needs admin-level access to inject the payload.

An attacker who has already obtained a high-privileged (administrative) FortiSIEM account submits a crafted HTTP request that stores a malicious script in the web interface. When another authenticated user later views the affected page, the script executes in their browser, potentially stealing session context or performing limited actions in their security authority. No public exploit code was identified at the time of analysis.