PHP2Shell on IBM i: which PHP you run decides what to install

PHP2Shell is not just a WordPress problem. The two PHP flaws patched on October 21, CVE-2026-109618 and CVE-2026-109619, hit every PHP version from 5.4 to 8.5 on every platform, and IT Jungle confirmed IBM i is on that list. Both rate 9.2 under CVSS v4.0, need no login, and CISA added them to its Known Exploited Vulnerabilities catalog on October 26. If your IBM i serves anything through PHP, the fix for PHP2Shell on IBM i depends on one thing most shops can’t answer from memory: which PHP distribution is on the box, and which version.

This is the decision, not the exploit. Find what you run, match it to the table, install, restart, check.

Why this one can’t wait for the next maintenance window

Amazon’s threat intelligence team saw an exploit attempt against one of its honeypots on October 17, four days before the patches shipped. Within hours of release it reported “broad exploitation attempts in the wild.” The release itself came two days early because, per Zend, a leak forced the PHP security team’s hand.

The part that matters for IBM i: Datadog Security Labs found that PHP processes the malicious request before your application code runs. Your PHP app’s sign-on screen, its framework, its input validation, none of that is in the path. A patched PHP runtime is the fix. Zend’s advisory calls updating “the only complete mitigation.”

And on IBM i, a compromised PHP job runs with whatever authority its user profile carries. If the HTTP Server instance runs PHP under a profile with more authority than it needs, that is the blast radius. We covered why that matters more now in what AI did to IBM i security-through-obscurity.

Find every PHP on the box first

There are two PHP distributions for IBM i on the market today: Seiden PHP+ and Perforce’s ZendPHP for IBM i. Many shops also still run Zend Server, Zend’s older all-in-one stack, and some have a PHP install nobody remembers approving. Check for all three before deciding anything.

From an SSH session as a user with access to the open source environment:

# Seiden PHP+ and ZendPHP both install as RPM packages
/QOpenSys/pkgs/bin/rpm -qa | grep -i php

# Zend Server installs as a licensed program, not an RPM
ls -d /usr/local/zendphp* /usr/local/zendsvr* 2>/dev/null

# Which HTTP Server instances load PHP at all
grep -il php /www/*/conf/httpd.conf

Read the RPM output for the version. Seiden packages are named php-* with the PHP version in the package version. ZendPHP packages carry the PHP version in the name, with a prefix such as php74zend-php for 7.4. For Zend Server, the PHP binary is typically /usr/local/zendphp7/bin/php-cli on Zend Server 9 through 2019, and GO LICPGM option 10 shows the Zend Server licensed program and its PHP version.

The grep matters more than it looks. It lists every HTTP Server instance that loads PHP, which is your restart list later. If it turns up an instance nobody in the room can explain, that is the one to look at first.

PHP2Shell on IBM i: what to install, by distribution

What you run	PHP version	What to install
Seiden PHP+	8.2, 8.3, 8.4, 8.5	8.2.35, 8.3.36, 8.4.27 or 8.5.12 via yum update "php-*"
Seiden PHP+	7.4, 8.0, 8.1	7.4.33-20seiden, 8.0.30-20seiden or 8.1.34-20seiden, same command
Seiden PHP+	7.3	Contact Seiden, decided case by case
ZendPHP	8.2 to 8.5	Zend’s patched build, through yum or zendphpctl
ZendPHP LTS	7.2, 7.3, 7.4, 8.1	Patched LTS build, needs your Zend LTS credentials
Zend Server	2021 release	Zend lists 2021.4.9 as fixed, confirm with Zend support
Any source	7.2 or older with no LTS contract	No patch. Upgrade

Sources: Seiden’s October 21 post and changelog, Zend’s October 22 post and its Security Center entry for CVE-2026-109618. One caution on the ZendPHP LTS row. Zend’s post lists the end-of-life versions it patched two different ways, with 8.0 in the summary and missing from the body, and Zend’s IBM i install guide lists its LTS versions as 7.2, 7.3, 7.4 and 8.0. If you run ZendPHP 8.0, get a written answer from Zend before you assume you’re covered.

Seiden PHP+: one command and a restart

Seiden shipped the update on October 21 and says it runs on IBM i 7.2 through 7.6. The changelog gives the install command:

yum update "php-*"

That updates whichever PHP version you have installed. It does not move you from 8.2 to 8.5. Supported versions land on the upstream fixed releases. The end-of-life versions get Seiden’s own back-ports, which you can spot by the -20seiden release tag in the RPM output.

Then restart every instance from your grep list, or the old PHP keeps running in the jobs already started:

ENDTCPSVR SERVER(*HTTP) HTTPSVR(instance_name)
STRTCPSVR SERVER(*HTTP) HTTPSVR(instance_name)

If you also run PHP from the command line in batch jobs or scheduled scripts, those pick up the new binary on their next run. Long-running ones need a restart too.

Plan one more thing if you’re on 8.2. The PHP community’s security support for 8.2 ends at the close of 2026, per IT Jungle’s September coverage of PHP on IBM i. You’re patched today and out of upstream fixes in eight weeks. Book the move to 8.4 or 8.5 now, while you have everyone’s attention.

ZendPHP and Zend Server

ZendPHP on IBM i installs from a yum repository that Zend’s zendphp_manage.sh script sets up in /QOpenSys/etc/yum/repos.d/zendphp.repo. Zend’s docs point to zendphpctl for updates, and the packages also show up in ACS Open Source Package Management, so you can update them there if your team prefers a screen to a shell. If ACS is your main tool for this, our ACS review covers where that panel lives.

ZendPHP’s end-of-life builds come from Zend’s paid LTS repository, which needs credentials in that repo file. No credentials, no LTS packages. If you’re on ZendPHP 7.x and don’t have an LTS contract, that is the conversation to have with Zend today, not a yum command.

Zend Server is the harder case. Zend’s Security Center lists Zend Server 2021.4.9 among the fixed products, and we found nothing else from Zend specific to the IBM i build. Open a ticket and ask for the fix level for your exact release. Zend Server also reaches end of life in December 2027 and Zend is steering customers to ZendPHP, so a patch here buys time on a stack with a published end date.

On 7.2 or older, or a PHP nobody owns

Seiden won’t back-port to 7.2 or older and says so plainly. Zend lists 7.2 in its LTS coverage, which only helps if you’re a Zend customer. For everyone else on old PHP, there is no package to install.

That leaves three moves, in order of how fast they cut exposure:

1. Take it off the internet today. If the instance faces customers or partners, restrict it to internal addresses or stop it until it’s upgraded. Several European governments pulled public sites offline while waiting for patches. You can do the same for one HTTP Server instance.
2. Upgrade the PHP, not the app first. Seiden offers a free PHP upgrade assessment, and Zend sells migration services. Either way, the fastest path is usually to the oldest supported version your code tolerates, then forward from there.
3. If you can’t do either this week, write down why. Your auditor will ask, and “we didn’t know PHP was on the box” is worse than a dated risk acceptance.

Old PHP on IBM i usually means an app the original developer built and left behind. If that sounds familiar, it’s the same knowledge-loss problem behind most IBM i incidents, and the IBM i AI Field Guide has prompts for documenting an inherited app quickly enough to upgrade it safely.

After the update: verify, then look back to October 17

Check that the patch landed. Re-run the rpm -qa command and compare versions against the table. For Zend Server, run php-cli -v with its full path. Then load a page from each restarted instance to confirm PHP is answering.

Then look backward. Amazon says investigations should start from October 17 at the latest. If a PHP instance faced the internet unpatched any time after that date, do three things:

• Review the HTTP Server access and error logs for that instance across the window, looking for anything you can’t account for.
• Check the IFS directories under that instance’s document root for files changed or added since October 17.
• Rotate the credentials the PHP app holds: the Db2 user profile password in its connection settings, API keys and tokens in its config files. Zend and Wiz both say the flaws can expose data from process memory, including passwords, tokens and keys.

If anything turns up, treat it as an incident, not a patching task. The August security PTF rundown has the general approach to scheduling fixes like these. This one is past the scheduling stage.

Bottom line

To patch PHP on IBM i, start with the three discovery commands today. If you’re on Seiden PHP+ at any version from 7.4 up, yum update "php-*" plus an HTTP Server restart closes PHP2Shell in one short maintenance window. ZendPHP shops on supported versions are in the same position. ZendPHP LTS and Zend Server shops need a confirmed fix level from Zend before calling it done.

If you find PHP 7.2 or older with no vendor contract, take it off the internet before you do anything else. There is no patch coming for it, exploitation attempts are already broad, and a php.ini tweak won’t save you.

Frequently Asked Questions

Does PHP2Shell affect PHP on IBM i?

Yes. CVE-2026-109618 and CVE-2026-109619 affect every PHP version from 5.4 to 8.5 on every platform, IBM i included. Both IBM i PHP distributions, Seiden PHP+ and Perforce’s ZendPHP, shipped updates built on the October 21 fixes.

What command updates Seiden PHP+ for PHP2Shell?

Run yum update "php-*" from an SSH session, then restart the HTTP Server instances that run PHP. Supported versions move to 8.2.35, 8.3.36, 8.4.27 or 8.5.12, and the end-of-life 7.4, 8.0 and 8.1 builds move to Seiden’s -20seiden back-ports.

Is there a PHP2Shell patch for PHP 7.2 on IBM i?

Not from Seiden, which says 7.2 and older must upgrade. Zend lists 7.2 among the end-of-life versions it patched through its paid PHP LTS service, so a Zend customer on 7.2 should ask Zend for the LTS build. Anyone else on 7.2 or older has no patch and needs to upgrade.

Can I block PHP2Shell with a php.ini setting instead of patching?

No. Zend’s advisory calls updating PHP the only complete mitigation, and the malicious request is handled before your application code runs, so application logins do not help. Configuration changes passed around online cover one path at most.