CVE-2026-17004

The fact that this infinite loop survives across IBM i 7.3, 7.4, 7.5, and 7.6 tells you something critical: this isn't a new bug in a recent feature. It's a logic error in code that has been carried forward through multiple major releases — likely a core parsing layer, protocol state machine, or resource enumeration routine that touches every version. Memory corruption bugs tend to get accidentally fixed by compiler changes; algorithmic loops do not. This explains why it has gone undetected: the specific input conditions that trigger the infinite loop probably haven't been hit in normal workloads until now. The operational blast radius is where this CVE gets dangerous beyond its 7.5 CVSS rating. IBM i systems typically sit at the center of enterprise operations — ERP, banking, manufacturing. An infinite loop doesn't just crash a service; it starves job queues, locks file systems in wait states, and can force hard IPLs (Initial Program Loads) on systems that haven't been restarted in months or years. A forced IPL on a production IBM i is a business continuity event, not just a security incident. The pre-authentication question is the single most important unknown. IBM's advisory says "remote attacker" without specifying session state, which historically means they haven't confirmed the trigger condition. Treat this as pre-auth by default in your threat model — defenders who wait for confirmation before hardening their perimeter are the ones who get hit in the gap between advisory and weaponization. From a patching perspective, this is a drop-everything priority if you're internet-facing. If it's truly pre-authentication, any automated scanner will add this within 48 hours of publication, and the exploit requires zero sophistication — a malformed packet is all it takes. Even if it's authenticated, IBM i shops routinely run with elevated privileges on service accounts, and a compromised account triggering this loop propagates through the job subsystem in ways that make targeted remediation nearly impossible without downtime. Finally: this is almost certainly not the only algorithmic flaw in this code family. The four-version persistence predicts something specific about fix reliability — auditing one state-machine bug in dormant code almost always reveals adjacent ones. Your remediation strategy shouldn't just be "patch this CVE" but should include: what else in this parsing layer survived four releases and hasn't been found yet?

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