CVE-2026-16859

The EPSS score of 0.00293 will tell you this is a low-probability exploitation case, and the CVSS 5.3 will tell you it's medium severity. Both signals suggest deprioritization. Both signals are dangerously incomplete for this vulnerability, and the gap is not in the scoring models—it's in what they were designed to capture versus what actually matters on IBM i. An out-of-bounds read does not enable code execution. That is the factual basis for the low EPSS probability. But on IBM i, the asymmetry works against defenders in a way the models cannot weight: an attacker needs only one read path that touches sensitive memory, while you must eliminate all such paths across an entire OS and middleware stack that spans REST APIs, ODBC connectors, and Db2 database buffers layered over C code written for a pre-network threat model. The genealogy of this vulnerability class is documented—modern API patterns threaded over memory-unsafe subsystems. Every new interface IBM adds (REST, GraphQL, ODBC over TLS) creates a new junction where this exact flaw pattern can resurface. The concrete triage questions for your environment: First, what IBM i version are you running? Version 7.3 reached end of support in April 2023. IBM will not patch it. If you are on 7.3, this is not a patchable vulnerability—it is a compensating control decision, and you must treat it as such. Second, does the vulnerable component sit at a modern API junction (anonymous-access REST endpoint) or in an older, authenticated subsystem (RPG job queue, DB2 connector)? The former creates broad exposure; the latter requires credentials but touches richer data. Third, what data was in process memory at the moment of your last authenticated session? IBM i concentrates sensitive operations into fewer memory spaces—authentication tokens, ODBC session handles, and inter-subsystem IPC buffers connecting to financial ledgers or patient records. An out-of-bounds read landing in any process that recently called those systems could provide pivoting information without achieving code execution. The remediation pipeline reality compounds the problem. IBM's patch cycle runs 90-180 days from internal discovery to advisory publication. For 7.3, the patch will never arrive. For supported versions, the gap between patch availability and production deployment routinely exceeds 60-90 days on IBM i due to regression testing requirements for RPG, COBOL, and Db2 workloads. By the time you finish testing, the next CVE in this vulnerability constellation has already dropped. The scoring models give you a snapshot. Your risk posture requires a trajectory analysis: how many unpatched IBM i vulnerabilities now exist in your environment, what data those systems touch, and whether your change management process can close the remediation window before the disclosure window becomes an active exploitation window. On a platform hosting financial and healthcare workloads, the answer to that question is the only metric that matters.

Reviewed through automated stages and approved by a human before publication.