IBM Db2 EUVD-2026-97765

Exploitation requires two concrete preconditions: (1) the db2locssh feature must be enabled for the Db2 instance - this is the exact configuration named in the vendor description and is the gating condition; and (2) the attacker must already have local, low-privileged access to the Db2 host (CVSS PR:L, AV:L), meaning this is a post-foothold escalation rather than a remote entry vector. Limiting factors that reduce real-world risk: the attack is not network-reachable, requires an existing local account, and depends on db2locssh being enabled (if this is not a default configuration, exposure is correspondingly narrower). Affected versions are limited to Db2 11.5.0 through 11.5.9 and 12.1.0 through 12.1.5; patched releases from IBM remove exposure.

This is a credible operational priority for environments running IBM Db2 with the db2locssh helper enabled, though not an emergency. The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, base 8.8) describes a locally-exploitable privilege escalation: an attacker must already hold a low-privilege foothold on the database host (PR:L), but once there, attack complexity is low and the scope change (S:C) with full C/I/A impact indicates escalation beyond the Db2 instance account - consistent with CWE-269 (Improper Privilege Management) and a likely path to root/OS-level control. No EPSS score, CISA KEV listing, or public POC is present in the supplied data, so there is no evidence of active or opportunistic mass exploitation; the risk is that of a post-compromise escalation primitive rather than an internet-facing entry point. Note a signal tension worth flagging: the 8.8 score is driven largely by the scope change and local low-privilege precondition, so the real-world severity depends heavily on whether db2locssh is actually enabled - a non-default-sounding configuration. The vendor (IBM) both reported and patched this, which raises confidence in the technical details but does not imply observed exploitation.

An attacker who has obtained a low-privileged local account on a Db2 host (for example via a separate application compromise or a legitimate but limited OS/instance user) abuses the db2locssh mechanism while it is enabled for the Db2 instance to escalate from that constrained context to higher privileges on the system. Because attack complexity is low and no user interaction is needed, the escalation is reliable once the precondition (local access plus db2locssh enabled) is met. No public exploit code is identified at time of analysis.