Your IBM i is patched. The laptops connecting to it aren't

The change control ticket says the security PTFs went on over the weekend. Forty CVEs, an IPL, everybody signed off. Nobody wrote a ticket for the thirty laptops that connect to that partition, and on most of them IBM i Access Client Solutions has not been touched since somebody unzipped it.

That is the patch window on almost every IBM i shop. It stops at the edge of the rack. IBM has published a run of client-side vulnerabilities through 2026 that nobody schedules around, including a remote code execution flaw scored 8.8 with no workaround, and one finding in IBM’s own changelog that should bother anyone who thought they were doing this properly.

What is actually on an IBM i developer workstation

Take an inventory of one workstation before arguing about severity. A typical IBM i developer PC has ACS installed, which means a 5250 emulator with saved session profiles, Run SQL Scripts pointed at production, an IFS browser, Data Transfer, a certificate truststore, and cached or saved credentials for every partition in the shop. If it is a Windows box it probably also has the ACS Windows Application Package, which is the ODBC, .NET and OLE DB driver layer plus the AFP printer driver.

Then add the editor. Either Rational Developer for i, which carries its own Eclipse stack, a debugger and a Code Coverage component with a browser interface, or VS Code with the IBM i extensions and a stored connection profile.

That machine holds an authenticated path to Db2 for i, write access to the IFS, and the credentials to use both. It sits on the general corporate network, gets carried home, and is patched by whatever endpoint tooling handles Chrome and Acrobat. None of that tooling knows what ACS is.

CVE-2026-7770: 8.8, no workaround, and a four-year version range

On 27 May 2026 IBM published a bulletin for CVE-2026-7770. ACS is vulnerable to remote code execution when it is configured to listen for requests from IBM i Navigator. IBM scores it 8.8 with the vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, and classifies it as CWE-74 injection.

Two things about that entry matter more than the score.

The affected range is IBM i Access Family 1.1.5.0 through 1.1.9.12. That is not a recent regression, it is most of the versions in the field. The fix is 1.1.9.13, which shipped in May 2026.

Under “Workarounds and Mitigations” IBM wrote one word: None. There is no configuration change, no firewall rule, no registry key. You update ACS or you stay exposed.

Be precise about the precondition, because it is real. The vulnerability applies when ACS is set up to listen for IBM i Navigator requests, and the PR:L in the vector means an attacker needs some privilege. Not every install is configured that way. But “some of our thirty machines, and we do not know which” is not a security posture, and finding out takes longer than updating.

The update channel was the vulnerability

Here is the finding worth the whole article, and it is sitting in plain text on IBM’s ACS updates page under version 1.1.9.14:

Versions 1.1.8.3 through 1.1.9.13 are vulnerable to downloading unverified product code when configured to update from an IBM i.

Read that against how IBM tells you to deploy ACS. One of the three documented update methods is pointing clients at a configured IBM i location and letting them pull, either through /plugin=installupdates or Help then Check for Updates. It is the method a well-run shop picks, because it is the only one that scales past a handful of machines.

That channel was not verifying what it downloaded. Version 1.1.8.3 predates 1.1.9.0, which shipped in April 2022, so this ran for at least four years and was only closed in August 2026. The shops that ignored ACS entirely were exposed. The shops that built the central update process IBM recommends were exposed through the process itself, and anyone positioned to modify what sat in that IFS path had a code delivery mechanism to every developer PC in the building.

The same August release fixed five other CVEs (CVE-2026-13094, 13105, 13433, 14866, 14875 and 16695), and IBM’s notes describe what “all prior versions” are vulnerable to: arbitrary code execution on Windows when ACS is installed for all users because the directory and configuration file are publicly writeable, injection of a rogue certificate authority because the truststore is publicly writeable, and a zip slip path traversal when importing a configuration. The sample scripts shipped in Documentation\Sample_Scripts\Linux_Mac_Other also execute arbitrary code from crafted input parameters.

A publicly writeable truststore on a machine that holds production database credentials is not an exotic attack. It is a file permission.

RDi has the same problem with a worse install story

Rational Developer for i is patched one developer at a time, through Help then Install New Software, with a file somebody downloads from Fix Central. There is no central push.

IBM published two bulletins for RDi on 27 February 2026. CVE-2025-48734 is an Apache Commons BeanUtils flaw scored 8.8, where an attacker reaching the declaredClass property of a Java enum gets to the classloader and executes arbitrary code, paired with CVE-2025-53057 in Java SE at 5.9. Both affect RDi 9.8.0.0 through 9.8.0.6 and are fixed by the 9.8.0.7 fixpack. Workarounds: none. The same day, IBM published CVE-2024-4068 at 7.5, a memory exhaustion loop in the Code Coverage component, affecting both RDi 9.8 and 9.9, with 9.9.0.0 remediated by interim fix 9.9.0.1.

Notice which components keep appearing: Code Coverage and the Debugger. Going back through 2024 the pattern holds, with buffer overflows in Debugger XML profile serialization and remote execution in Code Coverage Reports. Those are the parts of RDi most shops never open, bundled into the product whether or not anyone uses them.

The upgrade friction is real, and it is why shops sit still. RDi 9.9.0 went GA on 27 January 2026, and IBM states it requires a full install and cannot be applied as an update to an existing installation. A fresh install of a licensed Eclipse product on every developer machine is a project, so 9.8 shops stay on 9.8, and 9.8 is where CVE-2025-48734 lives.

Why the ACS PTF does not do what you think it does

This one causes real confusion in change control meetings.

CVE-2026-7770’s fix ships partly as 5770-SS1 PTFs: SJ09731 on 7.6, SJ09729 on 7.5, SJ09730 on 7.4, SJ09732 on 7.3. Someone applies those in the normal PTF window, the ticket closes, and the shop believes ACS is patched.

Those PTFs refresh the ACS installer image on the IBM i. They do not reach across the network and modify acsbundle.jar on anybody’s laptop. They are a prerequisite for the pull-from-host update method, not a substitute for it. Until each workstation runs an update, each workstation is on whatever version it had on Friday.

The August 2026 security PTF article told you to inventory the Application Package drivers before that window, and that was the right call for that batch. It said nothing about CVE-2026-7770, because that bulletin landed in May. Driver versions and base ACS version are two separate audits, and most shops have done neither.

IBM only fixes the current version

The other line on IBM’s updates page that shapes everything:

Fixes will only be provided for the current version.

There is no long-term support branch. No option to standardize on 1.1.9.9 and take security fixes for two years. The only remediation IBM offers for any ACS CVE is moving to the newest release, which means the shops most reluctant to move are accumulating exposure with no supported alternative.

The Application Packages make this worse. Windows, Linux, Mac and PASE are all at 1.1.0.29 from March 2026, and IBM’s page lists the next update as planned for May 2027. That is a fourteen-month gap on the ODBC and .NET driver layer, at the same time the August server PTFs started blocking older Windows Application Package drivers.

And the base package moves faster than most shops can test. Two releases landed in August 2026: 1.1.9.14 with the six security fixes, then 1.1.9.15 fixing an SSL certificate APAR. Anyone who staged and tested 1.1.9.14 had to move again inside the same month.

Partial updates are the other trap. Windows deployments that launch ACS through acslaunch_win-64.exe must update that file plus acsnative.dll and acspcoc.exe alongside acsbundle.jar, or the connection to the host fails. IBM has flagged this since 1.1.9.4, and APAR DT473152 covers the 1.1.9.12 and 1.1.9.13 version of the same problem, where the launcher will not start if the native files are not beside it. Shops hit that once, roll back, and quietly stop updating ACS.

The IBM i Access Client Solutions security update checklist

None of this is expensive. It is unowned, which is different.

Inventory the versions. Help then About in ACS gives you version and build id. Anything below 1.1.9.13 is exposed to CVE-2026-7770, anything below 1.1.9.14 to the August six. For RDi, anything below 9.8.0.7 on the 9.8 line or 9.9.0.1 on the 9.9 line needs the fixpack.

Check who is listening for Navigator requests. That is the precondition for the 8.8, and it is a per-configuration setting, not a global one.

Fix the file permissions before you argue about versions. A publicly writeable ACS directory, configuration file or truststore on an all-users Windows install is exploitable today regardless of version.

Update the whole deployment, not just the jar. If Windows machines launch through the exe, replace the exe, the dll and acspcoc.exe together, and back up AcsConfig.properties first if it has been customized.

Put the clients in the patch window. ACS ships roughly quarterly and RDi fixpacks land unpredictably, so the practical move is adding a client-version check to the same change record as the server PTFs. One line, four times a year.

Subscribe to My Notifications for the client products, not just the OS. IBM does not publish a security bulletin until a mitigation exists, so the bulletin and the fix arrive together. That works in your favour if you are actually reading them.

Bottom line

IBM i shops are good at server patching and have no process at all for the software that connects to the server. The result is a set of machines holding production database credentials, running versions with an 8.8 RCE and no workaround, updated through a channel that spent four years not verifying what it downloaded.

Spend an afternoon this month. Get a version list, fix the permissions on the all-users installs, move everything to 1.1.9.15 and the current RDi fixpack, and add one line to the PTF change record so the clients ride along next quarter. The hard part was never the work. It was that nobody’s name was on it.

The argument that AI ended security through obscurity on IBM i was about the server, and about source code becoming readable to anyone with a model. The client half is simpler and older. It was never obscure. It was just never inventoried.

If you are also rethinking which editor those developers use, the RDi versus VS Code comparison covers the tradeoff, and the ACS review covers what the client does well once it is current.

Frequently Asked Questions

What is CVE-2026-7770 in IBM i Access Client Solutions?

It is a remote code execution vulnerability that applies when ACS is configured to listen for requests from IBM i Navigator. IBM scores it CVSS 8.8 and lists no workaround. It affects IBM i Access Family 1.1.5.0 through 1.1.9.12, and the fix is ACS 1.1.9.13 or later.

What is the current version of IBM i Access Client Solutions?

The base package is 1.1.9.15, released August 2026, build id 6341, dated 2026-08-19. IBM’s page lists the next update as planned for September 2026. The Windows, Linux, Mac and PASE Application Packages are all at 1.1.0.29 from March 2026.

Does applying the ACS PTF on my IBM i update the ACS on developer PCs?

No. The 5770-SS1 PTFs refresh the ACS installer image on the host. Each workstation keeps running whatever version it has until someone updates that workstation. Applying the PTF is a prerequisite for the deployment methods that pull from the host, not a fix in itself.

Does IBM back-port security fixes to older ACS versions?

No. IBM’s ACS update page states plainly that fixes will only be provided for the current version. There is no supported path to stay on an older level and take security fixes, so the only remediation for any ACS CVE is moving to the newest release.