The EPSS score of 0.00307 tells a more important story than the CVSS 6.5 rating: this out-of-bounds write in IBM AIX and PowerVM VIOS has been modeled as having low automated exploitation probability, which means the actual attack surface is more constrained than a medium-severity rating implies. But the divergence itself is the signal — when EPSS and CVSS diverge significantly, it typically indicates the vendor disclosure documentation failed to precisely capture triggering conditions, required privilege level, or exposure context. The CVE description does not resolve whether this OOB write requires network-adjacent unauthenticated access or authenticated local access to trigger. If it requires shell access, the CVSS vector is misleading — this becomes a privilege escalation vector masquerading as a remote DoS, and the EPSS score is capturing a real constraint the CVSS number obscures.
The environmental context flips the prioritization calculus. AIX and PowerVM VIOS are not commodity endpoints — they run banking backends, government datacenter workloads, and the virtualization layer that consolidation environments depend on. Low target availability is not the same as low blast radius. When PowerVM VIOS goes down, it takes every LPAR it manages with it. That's not denial of service on one host; that's potential infrastructure collapse affecting hundreds of dependent systems. The vulnerability doesn't need to be easily exploitable to be catastrophic — it needs to be exploitable by a motivated actor targeting high-value infrastructure, and for that profile, 0.00307 is nearly irrelevant.
An out-of-bounds write that reliably triggers but scores low on automated exploitation almost certainly lives in a code path not exercised by common tooling — deprecated functionality, a legacy protocol handler, or backward compatibility code maintained for stability rather than security. These are the sediment layers where memory safety assumptions rotted: the subsystem nobody actively fuzzes because it's considered stable. CVSS 6.5 treats this as a generic medium; the low EPSS reveals it as archaeological evidence of a forgotten corner of the AIX codebase that needs excavation, not just patching.
Looking at IBM AIX CVE history over five years, memory safety issues cluster around specific subsystems — network stack handling and libc-adjacent code. One OOB write in isolation is noise; one that scores unusually low on exploitation probability in a codebase with documented patterns of similar issues signals either targeted research probing this surface or IBM quietly patching a cluster of related findings. When one memory corruption bug surfaces in a given subsystem, others frequently follow within 12-24 months as researchers turn to adjacent code paths. The constrained attack surface EPSS captures may constrain current exploitation probability while the underlying code quality issues remain a future vulnerability pipeline.
Organizations running AIX or PowerVM VIOS should resist deprioritizing this because EPSS says low probability. Deprecation is not eradication. That forgotten code path is still compiled into the running system, still exploitable if an attacker with specific knowledge decides you're worth the engineering effort. The analytical question is not whether the OOB write is hard to exploit — it's what the failure domain looks like when exploitation succeeds. Model failure cascades, not scoring comparisons.