IBM Guardium Data Protection EUVD-2026-95243

Exploitation requires two conditions drawn from the description: (1) the attacker must be able to influence database traffic that Guardium actively monitors, so a monitored database must be in scope and reachable by the attacker's queries/data; and (2) an authenticated Guardium user must subsequently open the Quick Search results grid, which renders the stored payload - this user interaction is a real limiting factor despite the vendor's UI:N rating. Limiting factors: the payload only executes within the browser of a logged-in Guardium operator (requires an active, privileged console session to victimize), and only when the specific Quick Search feature is used. No special non-default configuration is named beyond normal Guardium database monitoring being enabled.

IBM assigns CVSS 9.3 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N), but the signals do not uniformly support a top-priority rating. The high score is driven by PR:N (the injecting attacker is unauthenticated), S:C (scope change, consistent with script executing in a victim's browser rather than the Guardium server), and C:H. Two metrics are questionable for a stored XSS of this description. UI:N is unusual: the payload only fires when an authenticated Guardium operator opens the Quick Search results grid, which is effectively victim interaction (UI:R) - verify with vendor, as this inflates the base score. C:H is also aggressive for browser-context XSS where impact is typically session/data theft within the UI; C:L/I:L is more defensible. No EPSS score, no CISA KEV listing, and no public POC were provided, so there is no evidence of exploitation activity. Net assessment: a genuine, patchable flaw in a security product (which raises the stakes if the Guardium console is compromised), but exploitation is non-trivial - it requires injecting a payload into monitored database traffic AND a privileged Guardium user viewing the tainted grid. This is a prioritize-and-patch item for Guardium operators, not a widespread drive-by threat, and the 9.3 overstates real-world ease relative to the described preconditions.

An attacker who can generate or manipulate database traffic monitored by Guardium (e.g., by issuing SQL containing a crafted string against a monitored database) plants a stored XSS payload. When a legitimate authenticated Guardium analyst later opens the Quick Search results grid, the script executes in their browser, potentially hijacking their session or acting within the Guardium console on their behalf. No public exploit code was identified at time of analysis.