Security Verify Access EUVD-2026-95264

Exploitation requires a valid authenticated account on the IBM Security Verify Access / Verify Identity Access Web UI (PR:L) with the ability to submit input into a Web UI field that is rendered back without sanitization, plus a second user loading that content for the injected JavaScript to execute (UI:R). The scope-changing impact (S:C) means the payload runs in a victim's trusted session, enabling credential/session disclosure. Limiting factors: attacker must already be authenticated, exploitation is not automatic because it depends on victim interaction, and impact is confined to data accessible within the victim's session (no availability impact). Affects SVA 10.0 through 10.0.9.2 and VIA 11.0 through 11.0.3, including the container editions, per the CPE list.

This is a moderate-severity stored/reflected cross-site scripting issue (CVSS 5.4) rather than a top-priority emergency. The CVSS vector (AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N) tells a consistent story with the description: network-reachable but requiring an authenticated user (PR:L) and victim interaction (UI:R), with only low confidentiality and integrity impact and no availability impact. The scope change (S:C) reflects that injected script executes in another user's trusted browser session, which is what raises this above a trivial self-XSS. No EPSS score, CISA KEV listing, POC, or SSVC decision data was supplied in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation - the automatable and exploitation-maturity signals of SSVC cannot be evaluated from available data. The combination of required authentication plus required user interaction materially limits real-world risk, so despite the network attack vector this is better treated as a standard patch-cycle item than an urgent out-of-band fix, prioritized higher only in multi-tenant or shared-administration deployments where one authenticated user can reach another's session.

An authenticated user with access to the Verify Access/Verify Identity Access Web UI submits input containing arbitrary JavaScript into a field that is later rendered without proper sanitization. When another authenticated user (e.g., an administrator) views the affected page, the script executes in their trusted session, potentially harvesting session credentials or performing actions as that victim. No public exploit code was identified in the provided data, and success depends on the victim loading the malicious content (UI:R).