IBM i CVE-2026-107674

Requires a local, high-privilege account on the IBM i system (CVSS PR:H, AV:L) and is specific to the Digital Certificate Manager (DCM) component handling System TLS for applications creating secure network connections. Exploitation is triggered in the context of applications attempting to establish TLS sessions. Limiting factors: no remote network vector, no unauthenticated path, and the need for elevated privileges substantially reduce the realistic attacker population; the primary consequence is service unavailability or an insecure-connection fallback rather than code execution or data theft.

This is a moderate-severity, low-urgency issue rather than a top priority. The CVSS 3.1 vector (AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:H, base 5.1) confirms a LOCAL attack vector requiring HIGH privileges - the attacker must already hold a privileged account on the IBM i system, which sharply limits who can exploit it. The primary impact is availability (A:H) with a secondary confidentiality concern (C:L) stemming from the described fallback to non-secure connections. No EPSS score, KEV listing, or public POC was provided, so there is no public exploit identified at time of analysis and no evidence of active exploitation; the absence of these signals is consistent with a vendor-reported (IBM) defect disclosed alongside a patch rather than an attacker-discovered flaw. CWE-667 (improper locking) matches the denial-of-service description - a locking/deadlock condition in DCM's System TLS handling. All signals align (local, privileged, DoS-focused), with no conflicting data. The one notable nuance: C:L is assigned despite this being described primarily as a DoS, justified by the fallback-to-non-secure-connections behavior, which can downgrade transport security. Overall this is a patch-in-normal-cycle issue, not an emergency.

A user who already holds a highly privileged account on an IBM i system (or a compromised privileged service account) triggers a locking defect in the Digital Certificate Manager's System TLS processing while applications attempt to establish secure connections. This prevents a TLS-dependent service from starting or forces it to fall back to a non-secure connection, degrading availability and transport security. No public exploit code is known, and the local, high-privilege prerequisites make this a constrained scenario.