IBM Guardium CVE-2026-81933

Requires a valid authenticated account on IBM Guardium Data Protection 12.2 with at least low privileges (PR:L) and network reachability to the web console; the attacker must be able to reach the analytic cases grid endpoint handled by the Analytic Grid Service Handler and supply a malicious parameter. Limiting factors: exploitation is NOT possible unauthenticated (a console account is mandatory), it is constrained to the specific analytic cases grid feature/endpoint, and only Guardium Data Protection 12.2 is listed as affected. No user interaction by a victim is needed (UI:N).

CVSS 8.8 (High) with vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H describes a network-reachable, low-complexity SQL injection requiring only low-privilege authentication (PR:L) - a valid application account, which every operator of a Guardium deployment issues to analysts. The full C:H/I:H/A:H impact triple is consistent with direct SQL injection into the backend database, granting read of sensitive monitored data, tampering, and potential denial of service. Weighing all available signals: there is NO EPSS score, NO CISA KEV listing, and NO public POC in the provided intelligence, so exploitation is not demonstrated in the wild - this tempers the raw 8.8. SSVC-style reading: technical impact is total, but exploitation status is 'none observed' and automatability is limited by the authentication prerequisite. Net assessment: a genuine, patch-now-priority flaw for anyone running Guardium 12.2 because any authenticated analyst can escalate to database compromise, but the absence of exploitation evidence and the niche footprint place it below internet-facing unauthenticated criticals. No conflicting signals between vector and description - both agree on network vector plus low-privilege authentication.

A low-privileged authenticated Guardium user (e.g., a compliance analyst with a standard console account) submits a crafted parameter to the analytic cases grid endpoint served by the Analytic Grid Service Handler, injecting SQL that the backend executes without sanitization. This yields unauthorized reads of sensitive audit/monitoring data and the ability to modify or destroy records. No public exploit code is identified at time of analysis; exploitation requires a valid (even minimal) account, so it is not remotely unauthenticated.