Guardium Data Protection CVE-2026-84084

Exploitation requires a victim who is currently authenticated to the Guardium Data Protection 12.2 web interface (ideally a privileged/admin user, since the value is bypassing security restrictions) and who is induced to load attacker-controlled content (UI:R) while that session is active. It further depends on the absence or failure of anti-CSRF protections (tokens, SameSite cookies) on the targeted endpoints. The attacker themselves needs no credentials (PR:N), but cannot read responses - impact is limited to actions the victim's account is authorized to perform. These factors (required user interaction, dependence on an active privileged session, and same-origin read restriction) meaningfully limit real-world exploitation despite the network vector.

The vendor CVSS of 8.8 (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) rates this as High, but the full C:H/I:H/A:H impact is questionable for a CSRF (CWE-352) flaw. CSRF is a blind, state-changing attack: it forces a victim's already-authenticated browser to submit forged requests, but the same-origin policy prevents the attacker from reading the response, so a claimed C:H (confidentiality) is overstated - the real impact is integrity-primary (unauthorized state/config changes on behalf of the victim). No EPSS score, no CISA KEV listing, and no public POC accompany this record, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The primary limiting factors are UI:R (a logged-in Guardium user, ideally an admin, must be lured into loading attacker content while their session is valid) and the niche footprint of the product. Net: a legitimate but conditional issue, not a drop-everything priority; realistic severity is closer to mid-6 than 8.8.

An attacker crafts a malicious web page or email containing an auto-submitting form or hidden request targeting a Guardium Data Protection administrative endpoint. When an authenticated Guardium administrator visits the page while their session is active, their browser silently submits the forged state-changing request (e.g., altering a policy or account setting), and the server processes it as legitimate. No public exploit code is identified at time of analysis.