Patched PHP Servers: How We Handled PHP2Shell

We patched PHP servers the same day the PHP2Shell fix came out on Oct. 21, 2026. Attackers were already testing the bug, so we moved fast and checked our work as we went.

Our earlier alert told you what to do. This post shows what it looked like from the inside, and how we were secure, fast. You can copy the steps whether you run one website or a few.

If your site sits with a hosting company, you can mostly relax. You just need to ask them a question, and we cover it below.

What PHP2Shell is and who is affected

PHP is the programming language behind a huge share of websites. Sansec says two critical bugs, CVE-2026-109618 and CVE-2026-109619, let an attacker run code on a web server without logging in. Both are rated 9.2 on the CVSS v4.0 scale, which tops out at 10.

The flaws are in PHP itself, not in your website’s code. Sansec says researchers showed attacks working against WordPress, Drupal, Joomla, Nextcloud and other well-known PHP apps.

Sansec also reports that Cloudflare saw early attacks at 7:43 a.m. UTC on Oct. 21, hours before the 2 p.m. UTC release. watchTowr says details leaked online on Oct. 20 and that it sees exploitation in the wild.

Product	Affected	Fixed
PHP 8.5	Before 8.5.12	8.5.12
PHP 8.4	Before 8.4.27	8.4.27
PHP 8.3	Before 8.3.36	8.3.36
PHP 8.2	Before 8.2.35	8.2.35
PHP 8.1 and older	Affected	No fix from the PHP project; ask your vendor for a backport or upgrade

The versions come from the PHP project’s announcement.

How we patched PHP servers in about an hour

By late morning we had a list of every PHP install across our servers. It took minutes, not days. Every one was on a vulnerable version. That list is the reason the morning stayed calm.

Next we sorted the list by what faces the internet. Those went first.

Before changing anything, we looked for signs someone had already got in. We checked for web shells (small hidden files that give an attacker remote control), stray PHP files in upload folders, and tampered WordPress settings. We found none. The odd traffic in our logs was ordinary password-guessing on WordPress logins, not this exploit.

Then we took a snapshot of each server. A snapshot is a saved copy of the machine as it is right now, so we could undo any patch in seconds.

Our WordPress sites, our file-sharing server’s container image and our test copies were patched within about an hour. We used the security packages from the Linux distributions, such as Debian’s DSA-6574-1 and Ubuntu’s USN-8948-1.

We did not trust the version number alone. Distributions often fix a bug without changing PHP’s headline version. Ubuntu’s fix for its older 22.04 release, for example, is a build of PHP 8.1. So for each package we read the changelog to confirm the CVE fix was listed.

Then we restarted the PHP workers. A patched file on disk does nothing until the running program reloads it. Last, we checked that every site answered normally.

When you can’t patch yet

One third-party app had no fixed version from its vendor yet. We still had to protect it.

Sansec’s stopgap is to block multipart/form-data requests, the format browsers use to upload files. Sansec says every known trigger uses it. Our proxy now rejects those requests for that app.

The cost is that the app loses its upload feature for a few days. We think that trade is worth it. Sansec warns the rule can also break some forms, so test after you add it, and remove it once the real fix is in.

PHP’s own notes say partial measures reduce exposure but do not make an install safe. Only the update does.

One more catch from PHP: if you installed PHP from the volunteer-run Remi repository, it had no update on Oct. 21. Switch to your distribution’s packages or build from source.

Our take

This is our view, and you may see it differently. We think the fix itself was the easy part. The hard part is knowing what you run and getting in front of it before it bites you.

A small office doesn’t need fancy tools for that. A simple list of your websites, who hosts them and what PHP version each uses turns a scary morning into routine work. We’d also take a small, reversible trade, like losing uploads for a few days, over leaving a door open while waiting on a vendor.

What to do this week

• Ask your host which PHP version your site runs and when it was patched. PHP 8.1 and older get no official fix, so ask about a backport or a move.
• Write down what you run: each website, where it is hosted and who looks after it.
• If you manage your own server, snapshot first, patch internet-facing sites first, and read the package changelog for the CVE numbers.
• Restart PHP after patching, then click through your site to confirm it works.
• Can’t patch yet? Ask your IT person about blocking file-upload requests at the edge, and test your forms afterward.

If you’d like a second pair of eyes, we offer a free 30-minute assessment. We look at your computers, email and backups and tell you what to fix first. No cost, no contract. You can also read about our security services.

Sources

• PHP2Shell: Critical PHP RCE (Sansec)
• PHP 2026 release announcements (PHP project)
• CVE-2026-109618 security tracker entry (Debian)
• USN-8948-1: PHP vulnerabilities (Ubuntu)
• PHP Remote Code Execution (PHP2Shell) (watchTowr)

This article was drafted by Percival, Rainier IT’s AI writing assistant, from the sources linked above, and reviewed by Christopher Engelhardt before publication. Spot an error? Email [email protected].