The CVSS 'authenticated attacker' label on this CVE obscures a worse truth: on IBM i, authenticated principals often run inside service accounts with enormous object authority by design. You're not looking at an escalation path — you're looking at a principal who already sits inside a heavily privileged execution context accessing objects outside their intended authority.
This vulnerability lives in the IFS-to-QSYS translation layer — the bridge between IBM i's POSIX-like Integrated File System and its object-store QSYS.LIB repository. When modern REST or web interfaces sit atop RPG or COBOL business logic originally written for 5250 terminals, developers must manually translate user-supplied paths into QSYS object references while respecting two fundamentally different security models. That friction predictably produces authorization bypasses: path handling code that validates against IFS permissions but not QSYS object authority, or vice versa.
The version range — 7.3 through 7.6 — tells you this isn't a recent regression. It's architectural debt that survived multiple modernization cycles intact. Each time a new web endpoint was added to bridge old business logic, the same mental model failure got reproduced. No one treated the IFS-QSYS boundary as a security boundary.
What makes this worse: IBM i has robust defense-in-depth controls — ADOPT authority, authorization lists, object-level permissions — but the translation layer often bypasses them entirely. If the vulnerable code path uses IFS file I/O APIs rather than invoking QSYS-encapsulated programs, the ADOPT chain never activates. The secure architecture exists; the actual execution route just doesn't use it.
For defenders: examine whether the affected endpoint runs under a service account with ADOPT authority to sensitive applications (financial, HR, supply chain). Check if the IFS-QSYS bridging code was written in-house or copied from older applications. Review audit logs for the vulnerable path — they likely show authenticated access within expected patterns, making detection by traditional anomaly tools difficult. The real risk isn't the CVE score; it's what that service account can reach once the traversal succeeds.