IBM Db2 CVE-2025-33012

Requires a pre-existing IBM Db2 for Linux account (versions 10.5.0-10.5.11, 11.1.0-11.1.4.7, 11.5.0-11.5.9, or 12.1.0-12.1.3) whose account has entered a lockout state and whose password has passed its expiration date; the actor must possess that expired password. Exploitation is limited to the Linux edition of Db2 and depends on account lockout/password-expiration enforcement being in use - accounts with current credentials or environments not relying on these controls are unaffected. The need for valid (if expired) credentials and a specific locked/expired account state substantially narrows realistic exploitation to insiders or holders of stale credentials.

The vendor-supplied CVSS of 8.8 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) is sharply inconsistent with the described behavior and should be treated with caution. The description (CWE-324, use of a key past its expiration date) states only that an already-authenticated user can regain access after account lockout because an expired password is still accepted - this is an authentication/access-control weakness that restores the user's own prior privilege level, not an unauthenticated path to full confidentiality, integrity, and availability compromise. The C:H/I:H/A:H impact metrics therefore appear overstated relative to the text; verify scope with IBM. All exploitation signals point to low real-world urgency: EPSS is 0.03% (10th percentile), there is no CISA KEV listing, and no public proof-of-concept was identified. No SSVC decision data was provided. Net assessment: this is a high-CVSS-but-low-real-risk issue - a genuine access-control hygiene defect worth patching in the normal cycle, but not an emergency given the absence of exploitation signals and the requirement for a pre-existing (expired) credential.

A user whose Db2 account has been locked out and whose password has passed its expiration date still possesses the old (expired) password; instead of being denied, they authenticate successfully and regain their previous database access. No public exploit code was identified, and the action requires knowledge of the account's expired credentials, so this is opportunistic misuse by an insider or someone holding stale credentials rather than a mass-exploitable remote attack.