CVE-2026-13094

The 'installed for all users' qualifier in IBM i Access Client Solutions is not a mitigating control — it is a scope delimiter that defines the vulnerability's reach. When installed for all users, the application's configuration file resides in a directory writable by standard users (typically ProgramData). The application loads this configuration without integrity verification, allowing any local user to modify it to point to a malicious DLL or executable. When a higher-privileged account launches or interacts with the application next, that code executes in their security context. This is a classic privilege escalation across the user-to-privileged-process boundary. The CVSS 7.8 accurately reflects the technical severity: a standard user can gain code execution in a privileged security context. However, the EPSS score of 0.00147 measures automated exploitation probability against the general internet — it tells you who is not coming through the front door with an automated exploit script. It tells you nothing about the threat model that actually applies here: enterprises running IBM i Access are financial institutions, healthcare organizations, and manufacturers where multi-user Windows systems are the operational norm, and where an insider or an attacker who already holds domain-user access would have both the motivation and the patience to exploit this. The deeper failure is architectural: a design decision allowed configuration data to live in a user-writable location and trusted that file implicitly at runtime. The fix cannot simply be 'do not install for all users' because that breaks legitimate multi-user workflows. The vendor must implement either signed configuration files with runtime verification, or a separate privileged process that validates the config before the GUI component loads it. Without one of these, the vulnerability persists in any environment where multiple users share Windows workstations — which is precisely where IBM i Access is deployed. Probe your environment: does IBM i Access communicate with a Windows service running as SYSTEM, or only with user-launched GUI components? That distinction determines whether the escalation path is domain-user-to-admin or domain-user-to-service-account, and the latter significantly expands the blast radius. If the application has undocumented service dependencies creating privileged code paths, that is a remediation scope issue beyond the CVE itself.

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