CVE-2026-18846

The CVSS 7.5 rating on this IBM i host server buffer overflow is deceptively reassuring. While the DoS-only outcome suggests memory protection mechanisms are catching corruption before arbitrary code execution, this is not a reason to deprioritize—it reflects an exploit chain that requires additional primitives (heap grooming, ROP, or info leaks), which attackers develop post-disclosure. The constraint is an exploitation complexity variable, not a permanent barrier. Your operational risk starts with the dependency graph. IBM i host servers don't crash in isolation—a DoS takes down integrated RPG applications, database access paths, scheduled jobs, and terminal sessions. A server process failing mid-transaction during GL posting or inventory reconciliation becomes a data integrity incident, not a technical footnote. Map your host server connections before you assess severity. The more uncomfortable reality is the deprecated-code exposure. This parsing logic almost certainly lives in a code path formally deprecated by IBM but retained for legacy client compatibility—present in the binary, unmaintained, unfuzzed, and silently processing production input. The absence of recent commits to this path isn't evidence of quality; it's evidence of abandonment under compatibility pressure. Assume any deprecated parsing path in your IBM i environment is a candidate for similar findings. On remediation timing: IBM i PTFs require application-layer testing that generic OS patching doesn't. The gap between 'patch available' and 'patch safe to deploy' in IBM i environments routinely stretches to months. A 0.00392 EPSS score will not protect you during that interval. Prioritize your host server inventory now, identify deprecated parsing paths still handling client input, and treat any buffer overflow in these components as a data integrity risk first, a DoS second.

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