IBM Guardium Data Protection 12.0, 12.1, and 12.2 is vulnerable to SQL injection. A remote unauthenticated attacker could send specially crafted SQL statements, which could allow the attacker to view, add, modify, or delete information in the back-end database.
**Risk verdict:** Treat this as a high-priority exposure for externally reachable deployments; no KEV or SSVC exploitation status is supplied, so active exploitation urgency cannot be confirmed.
**Why this matters:** Successful exploitation could expose or alter information held in Guardium’s back-end database, undermining the confidentiality and integrity of a security monitoring platform. An attacker may seek sensitive monitoring data, tamper with records, or disrupt investigation and compliance workflows; the absence of authentication makes perimeter exposure especially important.
**Most likely attack path:** The vulnerable Sniffer component must be reachable over the network; exploitation appears to require neither credentials nor user interaction and has low complexity. Scope is unchanged, so the stated impact is within the affected system rather than indicating direct compromise of other systems, though altered monitoring data could affect downstream decisions.
**Who is most exposed:** Prioritise organisations running the affected releases where Sniffer interfaces are accessible from untrusted networks, partner networks, or broad internal segments. The supplied data does not establish whether exploitation is observed or a public PoC exists; EPSS is also missing.
Review Sniffer-facing web and application logs for unusual SQL syntax, errors, or atypical request parameters.
Check for unexpected database reads, writes, deletions, or privilege changes.
Correlate suspicious requests with new accounts, altered policies, or gaps in monitoring output.
Mitigation and prioritisation
Apply IBM’s latest Sniffer patch for the installed release; verify successful deployment.
Until patched, restrict Sniffer access to trusted management networks and block unnecessary ingress.
Preserve relevant logs and validate database integrity and monitoring records after patching.
Confirm KEV, SSVC, and EPSS status before final queue placement; escalate if exploitation evidence emerges.
A considerable amount of time and effort goes into maintaining this website, creating backend automation and creating new features and content for you to make actionable intelligence decisions. Everyone that supports the site helps enable new functionality.
If you like the site, please support us on Patreon or Buy Me A Coffee using the buttons below.
The full story
This article is one source in a clustered incident — the cluster page carries the summary, timeline and every other outlet covering it.
