CVE-2026-16878

The CVSS 5.4 score for this out-of-bounds read is misleading precisely because it treats 'authenticated attacker' as a meaningful qualifier. In IBM i's architecture, authentication is not equivalent to trust boundaries — and treating it as such has created a systematic underestimation of exposure across the installed base. The critical misunderstanding is this: IBM i grants authenticated access through dozens of entry points that require no elevated privileges. QDIRSRV directory services, ODBC and JDBC connections from internal applications, legacy FTP servers still enabled for integration work, and web services running under standard user profiles all satisfy the 'authenticated attacker' condition. A compromised application server or a disgruntled employee with basic system access can trigger this OOB read without touching any privileged function. But the deeper problem is architectural. IBM i's memory model doesn't follow traditional kernel isolation patterns — it uses a Licensed Internal Code layer with object-based addressing where authority, not memory isolation, is the actual boundary. An OOB read that appears to be constrained by a low-privilege user profile may actually be reading data that the same profile's authority covers: user profile attributes, object authority information, PTF metadata, and system values that would otherwise require separate privileged queries. The 'authenticated but limited' actor isn't as limited as the CVSS framework assumes. This matters for prioritization because the OOB read likely feeds directly into privilege escalation chains that CVSS measures in isolation. Information disclosure at the OS layer in IBM i isn't a standalone impact — it's the reconnaissance phase that enables lateral movement to higher-privileged profiles. Environments where the same user profile runs business logic and system services are particularly exposed, and this pattern is common precisely because IBM i's job architecture makes profile isolation difficult without breaking application compatibility. The EPSS score of 0.00295 is not a reliable indicator of low exploitability. EPSS derives from observed exploit activity and researcher attention, both of which are thin for IBM i compared to mainstream platforms. Low scores reflect low visibility into IBM i environments rather than low exploitability — and the population of researchers with the specialized knowledge to develop IBM i exploits is small but not indicative of difficulty. When you combine this with the reality that IBM i systems routinely go 90 to 180 days between patches due to change management overhead, the actual exposure window far exceeds what EPSS's 30-day model captures. The 7.3 through 7.6 version span is also notable. Four major releases sharing this code path suggests either a long-standing latent defect or an interaction layer that wasn't adequately isolated during release divergence. Either way, organizations on 7.3 should treat this as a signal of accumulated interface debt. Prioritize this patch higher than the CVSS score suggests. The authenticated attacker requirement is not a meaningful security boundary in IBM i's threat model.

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