ACS 1.1.9.14: why this update cannot wait

IBM i Access Client Solutions 1.1.9.14 came out in August 2026. It is not a feature update: it is a security update, and it fixes six vulnerabilities.

CVE-2026-13094 · CVE-2026-13105 · CVE-2026-13433 · CVE-2026-14866 · CVE-2026-14875 · CVE-2026-16695

What was exposed

Earlier versions are vulnerable to a set of problems worth reading one by one, because they describe different scenarios:

• Arbitrary code execution on Windows when ACS is installed for all users: the directory and the configuration file turn out to be writeable by anybody using the machine.
• Injection of a rogue certificate authority, because the truststore is writeable. In plain words: somebody can make ACS accept a certificate it should not accept.
• Zip slip (path traversal) when importing a configuration. A configuration file received from somebody can write outside the intended folder.
• Versions 1.1.8.3 through 1.1.9.13 download unverified product code when configured to update from an IBM i.
• The sample scripts in Documentation\Sample_Scripts\Linux_Mac_Other execute arbitrary code through maliciously crafted input parameters.

The fourth point is the one to look at twice

Updating ACS from a shared folder on the IBM i is the configuration normally recommended, and it is the one almost every tidy installation has: you put the package in a single place, clients take it from there, nobody walks the offices with a USB stick.

It is also the path which, from 1.1.8.3 through 1.1.9.13, does not verify what it downloads.

Which means whoever did the right thing, centralising distribution, has the window open, and whoever updates one client at a time by hand has it shut: the recommended configuration is the exposed one.

How to find out which version the clients have

Inside ACS: Help → About. Fine for one machine, not for forty.

For a fleet the useful piece of data is the AcsConfig.properties file on the clients, or, if distribution is centralised, the version of the package in the folder everybody draws from, which is the place to fix first: as long as a 1.1.9.13 sits there, every client that updates goes on picking up the vulnerable version.

What to do, in order

1. Replace the package in the distribution folder with 1.1.9.14. It goes first: it is the source the other clients draw from.
2. Update the clients. The ones configured to update themselves will pick up the new version at the next start.
3. Check the permissions on the installation folder on Windows machines where ACS is installed for all users: if they are writeable by anybody, the problem stays even on an updated version, because it is the machine that is configured badly.
4. Throw away the sample scripts if you do not use them. They are in Documentation\Sample_Scripts\.

Example: the census before the upgrade

The problem with ACS is not upgrading it, it is knowing who has which version. The client lives on the workstations, not on the system, and nobody updates it on their own.

The round that works is this.

Ask the system who has connected recently. Client connections go through the host servers, so they leave a trace: profile and origin can be read with NETSTAT OPTION(*CNN) while they are active, or, if the audit journal is on, with SYSTOOLS.AUDIT_JOURNAL_PW, the route described in turning on the audit journal.

What comes out is a list of workstations, not people. That is what is needed: upgrades are done per workstation.

On each one the version is read from ACS, under Help → About. Anyone on an earlier 1.1.9.x falls within the upgrade.

The figure that nearly always surprises is the gap between the profiles catalogued and the workstations found: the latter are more numerous, because the same profile is used from several machines; which is exactly why the list has to be built rather than remembered.

What the previous version brought

1.1.9.13 is the one shipped alongside the July 2026 Technology Refresh. It brought support for the SQL Error Logging Facility (SELF) inside Run SQL Scripts and new SQL examples aimed at measuring the security posture of the system. They are useful additions, and they all remain in 1.1.9.14: updating takes nothing away.

Not to be confused. There is a separate, earlier bulletin, CVE-2026-7770, concerning remote code execution when ACS is configured to listen for requests from IBM i Navigator. That is a different matter from the six in this version.

Which versions this works on

It concerns ACS as a client program, on Windows, Linux and macOS, regardless of the IBM i release it connects to. The update-from-IBM-i vulnerability concerns versions 1.1.8.3 through 1.1.9.13 inclusive.

Sources

• IBM Community — ACS 1.1.9.14 is released — list of the fixed CVEs
• IBM i Access — ACS Updates — official download page
• Security Bulletin CVE-2026-7770