Guardium Data Protection CVE-2026-81656

Requires a valid low-privileged authenticated account on IBM Guardium Data Protection 12.2 and network reachability to the appliance's REST interface, specifically the New Query Builder REST Processor (newQueryBuilder endpoint). No user interaction and no elevated/admin privileges are needed (PR:L, UI:N), and no non-default configuration is called out in the description - the injectable endpoint is part of standard Query Builder functionality. The principal limiting factor is the authentication requirement: exploitation is gated by possession of, or ability to obtain, low-privilege Guardium credentials; it is not exploitable pre-authentication.

This is a genuinely high-priority vulnerability, not a high-CVSS-but-low-real-risk case. The vendor CVSS of 8.8 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) is internally consistent with the description: a direct first-order SQL injection (CWE-89) reachable over the network through the newQueryBuilder REST endpoint by any low-privileged authenticated user, yielding full CIA impact on the backend database. I largely agree with the vendor score; the only realistic downgrade lever would be AC:H if the endpoint or query grammar required significant discovery/tuning, but a directly-injectable REST parameter typically warrants AC:L. Signals are asymmetric: a vendor patch is confirmed (IBM node 7288040), but there is NO EPSS score, NO CISA KEV listing, and NO public POC provided in the input - so exploitation is a capability-driven risk rather than a demonstrated in-the-wild one. Weighing these together: the technical impact is high and the barrier is only a low-privilege account, but the absence of KEV/EPSS/POC means this reads as a serious latent risk to patch promptly rather than an emergency under active mass exploitation. Note the 'Authentication Bypass' tag conflicts with the actual mechanism (the attacker is already authenticated at PR:L; this is injection, not auth bypass) - treat that tag as erroneous.

A low-privileged but authenticated Guardium user (or an attacker who has phished/reused such credentials) sends a crafted request to the newQueryBuilder REST endpoint with SQL metacharacters embedded in a query-builder parameter. The injected statements execute against the Guardium backend database, letting the attacker read, alter, or destroy audit and configuration data - undermining the very compliance/monitoring appliance it runs on. No public exploit code is identified at time of analysis, and exploitation requires valid low-privilege credentials.