The EPSS score of 0.00289 badly mischaracterizes the actual risk profile for this vulnerability. EPSS models mass-scanning exploitation probability, but IBM i systems are not random internet targets — they're high-value infrastructure at banks, manufacturers, and industrial firms that attract nation-state actors and ransomware operators who conduct sustained, targeted reconnaissance rather than opportunistic sweeps. For these threat actors, a remote, unauthenticated DoS isn't interesting because it's novel; it's interesting because it's reliable and operationally useful for pre-ransomware disruption or hacktivist posturing. CVSS 5.3 reflects the absence of confidentiality or integrity impact, but DoS against IBM i cascades into business-critical process interruptions — a banking core dropping mid-transaction, a manufacturing SCADA losing heartbeats, an ERP halting order processing — with regulatory reporting implications and SLA penalties that far exceed what the technical severity score implies.
The "remote and unauthenticated" phrasing warrants skepticism. IBM i traditionally runs behind strict network segmentation with OS-level security primitives. Push for clarification on whether this requires a valid IBM i user profile or can be triggered from an unauthenticated socket — and which specific service program or API contains the off-by-one. That distinction determines whether you're looking at a mass-internet vector or an internal lateral movement tool.
The bug affecting every supported version (7.3 through 7.6) suggests shared code paths that weren't audited for boundary conditions. Historical advisories show similar off-by-one patterns in IBM i service programs — this is structural, not coincidental. Treat the disclosure as a canary: similar boundary-condition flaws almost certainly exist in adjacent code paths that haven't been disclosed.
The post-disclosure window is where real exposure compounds. Once the patch is public, motivated attackers can binary-diff it to identify the vulnerable code path. IBM i patching cycles are measured in quarters due to 24/7 workloads and regression testing requirements — the window between patch release and widespread deployment stretches months, and during that time the patch itself becomes the exploit blueprint. Operate from the assumption that threat actors are already reverse-engineering this fix.
What to do: confirm the exact component and authentication context with IBM, treat this as an audit trigger for similar boundary-condition patterns in your IBM i environment, and accelerate patching timelines knowing the post-disclosure risk amplification is real.