Code for IBM i security going forward

[worksofliam]

The Code for IBM i team has just published their first CVEs ever. They were discovered before the release of 3.0.0 and are fixed in 3.x onwards. This post is to explain the cause of these CVEs and what we did to fix them.

Uses IBM i components with blind check allowing arbitrary code execution (CVE-2026-49483)

With Code for IBM i 2, we introduced a feature called the component system. This allowed us to add optional features to Code for IBM i, which meant users who had more flexability on their system could make use of these enhancements, while more locked down users could live without them. The example the CVE uses is simple: GETMBRINFO (get member info).

GETMBRINFO gets created on the server by whichever user connects first, which created a re-usable SQL stored procedure across the system. It won't get created again if it already existed. We used the procedure comment property to determine the version, which allowed us to have multiple versions of the same component. That is the entire problem. Any user who can modify the installed IBM i component can cause other users to execute attacker-controlled code when using the extension.

What we did to fix it

After much discussion amongth the core team, Sébastien made a PR which mainly does two important things:

1. Replaced all SQL based components in the base extension (Code for IBM i) with runtime SQL to achieve the same results. This means a faster connection time, and providing functionality to the user without any hard object requirements on the server.
2. Allowed components to be defined with a fixed signature/hash. This means if we do depend on an object on the server (either in the IFS or QSYS), then we can compare the hash of the version on the system to the hash we expect, which means we can determine if the object was changed. Once a version of an object is built, it will never change again, and therefore the hash check is a simple but safe check for us.

Temporary files are visible to all users (CVE-2026-49484)

Since the beginning of the project, we have had to use temporary files for many reasons. Originally, it was for us to read the contents of outfiles. Today, we still use temporary files if you aren't using source dates (which uses SQL instead) when reading source code from the server.

On most IBM i system, /tmp is usable and reable by anyone. So if all developers are placing temporary files in there, that could potentially leak if a bad actor was able to access that system.

What we did to fix it

While we avoid the use of temporary files as much as possible in 3.x+, both Julia and Seb made fixes to enforce the temporary directory to be inside the user's home directory going forward. This aligns with locking down the home directory between each user, and not sharing data between them.

Going forward

Here are the two things that we're going to keep in mind going forward:

We need to be mindful of how we are using the component API. We should avoid creating QSYS objects where we can recreate the same functionality with runtime SQL, though if we are required to use objects, we should make sure we're using the hashing functionality as expected to secure it.

Across the entire Code for IBM i family of extensions we need to be keeping our dependencies up to date. This is a no brainer and we have Dependabot that helps some, but we can be more proactive in this area. Lastly, we should consider enforcing npm 12 or switching to pnpm.

As always, the Code for IBM i team believes in open-source, and that also means being transparent with the community. Please reach out to us with any questions you have, and please also reach out to us to share anything you might be concerned about.