PHP2Shell: A Portfolio Checklist for Agencies Running PHP Client Sites
By Mykhailo Sokolov
What is PHP2Shell, and which client sites does it affect?
On October 21, 2026, the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two vulnerabilities that can allow unauthenticated remote code execution. CVE-2026-109618 is in out-of-memory handling, which can leave request memory in an invalid state that cleanup then trusts. CVE-2026-109619 is stale internal state that survives into the next request handled by the same worker. CISA, which calls the pair "php2shell", issued an alert the same day and added both to its Known Exploited Vulnerabilities catalog on October 26. The PHP project scores both 9.2 (Critical) under CVSS 4.0, and NVD's own CVSS 3.1 assessment puts them at 9.8 and 8.1.
The PHP project says the scope is "all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed", with the highest risk on mod_php, where the demonstrated exploit runs before any application code does. For an agency, that is the part that matters. This is a bug in the PHP runtime, not a WordPress plugin or a Drupal module, so nothing in the CMS admin fixes it. Every WordPress, Drupal and custom PHP site you look after stays exposed until the PHP underneath it is updated, however carefully the application itself is maintained.
Which PHP versions are fixed, and what about 8.1 and older?
| PHP branch | Release that fixes both CVEs | Security support ends (php.net) |
|---|---|---|
| 8.5 | 8.5.12 | 31 Dec 2029 |
| 8.4 | 8.4.27 | 31 Dec 2028 |
| 8.3 | 8.3.36 | 31 Dec 2027 |
| 8.2 | 8.2.35 | 31 Dec 2026 |
| 8.1 and older | No official release | Already end of life |
Sources: the php.net advisory, the php-src advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp, and php.net's supported versions page.
"No official release" for 8.1 and older needs reading precisely. The PHP project says those branches "no longer receive updates from the PHP project". Given the severity, its security team did publish minimal source backports for PHP 7.4, 8.0 and 8.1, aimed at people who build PHP from source or have no LTS vendor, and some Linux distributions and LTS vendors ship their own backported fixes. CISA's guidance is blunter: organizations that cannot update immediately, or that still run PHP 8.1 or earlier, "should take PHP-based systems offline until they can be patched or updated." In practice, a backport is a stopgap for a server you compile yourself. It does not return the branch to support.
How do you check a whole client portfolio quickly?
CISA's first action is to "identify and inventory systems running any version of PHP." Across a portfolio, that means one row per site, not one row per client. Work through it in this order.
1. Build the inventory. For each site, record the client, the host, the type of hosting (shared, managed, VPS, your own server), and who controls the PHP version: you, the client, or the host. Then record the PHP version the site actually serves web requests with. The CMS will show it (Site Health in WordPress, the Status report in Drupal). Don't trust a command-line php -v on the server, because the CLI binary and the web server's PHP can differ. Add the handler if you can find it: mod_php, PHP-FPM, LiteSpeed or something else.
2. Don't read the version number as a verdict. Linux distributions and LTS vendors got the patches in advance, and some ship fixes backported into packages whose version string looks older than the table above. An older-looking number is a question for the host, not proof the site is exposed. A matching number on a server nobody has restarted isn't proof it's fixed, either.
3. Triage. CISA says to prioritise internet-facing systems, and the PHP project ranks mod_php as the highest risk. A workable order:
- public sites on mod_php
- anything on PHP 8.1 or older
- everything else on a supported branch
Count staging and development copies that sit on public URLs. They serve web requests too, and they are often the oldest PHP in the portfolio.
4. Patch what is patchable. A site on 8.2 to 8.5 needs a point release within its branch. That is usually a low-risk update the host or your server build can apply. A site on 8.1 or older needs a branch upgrade, and that is a compatibility project: CMS core, every plugin or module, the theme and any custom code all have to run on the new branch, so test it on staging first.
5. Use stopgaps only as stopgaps. The PHP advisory lists configuration measures that reduce exposure to specific attack paths, including disabling session.upload_progress and lowering post_max_size, and states plainly that "only an update is a complete solution." CISA adds that a web application firewall "may provide some protection" until systems are updated. Apply the measures from the advisory itself rather than a summary of it.
6. Watch for the signal CISA names. CISA's alert tells defenders to monitor for "PHP worker processes launching shells or downloading tools." If you run your own servers, that is the alert to set up. If the host runs them, ask the host whether it is watching for it.
7. Write down what you did. Record the site, the version before and after, the date, and who confirmed it. You'll need this record for the client email and again for the next advisory.
What should you ask each hosting provider?
Send these as one message per host, listing the sites concerned:
- Which PHP version and package is serving each of these sites right now, and does it include the fixes for CVE-2026-109618 and CVE-2026-109619? If it's a vendor backport, which advisory or package release?
- Which handler runs each site: mod_php, PHP-FPM, LiteSpeed or another?
- Were the PHP processes restarted after the update, so that the patched code is what's running?
- For any site on PHP 8.1 or older: which supported version can this plan run, and when can the site move?
- Have you seen PHP worker processes launching shells or downloading tools on these accounts since October 21?
- How will you notify us of the next PHP security release, and who is our contact?
Any host that cannot answer the first question for a specific site has given you useful information about that host.
What should you tell your clients?
Tell them before they ask. A client who reads about a critical PHP vulnerability elsewhere and hears nothing from their agency starts wondering what else they haven't been told. Keep the message short, factual and specific to their site:
On October 21, the PHP project fixed two critical vulnerabilities in PHP itself, the server software your website runs on. The fix is an update on the server, not a change to your site's content or design. Your site was updated to PHP [version] on [date] (or: is scheduled for [date]). We have checked [what you actually checked] and will tell you if anything changes.
For a site on 8.1 or older, add one sentence and keep the rest of the conversation for later: Your site runs on a version of PHP that no longer receives updates from the PHP project; we'll send you a separate recommendation and cost to move it to a supported version.
Three rules keep this honest. Don't write "you're safe": write what you checked. Don't put the upgrade pitch in the alert email. And settle who pays before the next alert, not during it. A point release usually fits a maintenance retainer; a branch upgrade is a project.
Why does a portfolio on old PHP branches keep costing you?
This advisory will be patched and then forgotten. The calendar won't. PHP 8.2's security support ends on December 31, 2026, so a client site patched to 8.2.35 now needs a branch upgrade within weeks to stay supported. 8.3 ends a year later, then 8.4. Every branch has an end date, and each date turns into compatibility testing, a staging run and a client conversation for every site on that branch.
The real cost isn't any single CVE. It's that each client site carries its own runtime on its own host, so every PHP release means one inventory, one ticket and one email per site. With thirty sites across eight hosts, a single critical advisory means thirty separate jobs, and they all land in the same week. Most of those hours sit outside what a typical retainer was priced to cover.
What changes when client sites move to a managed platform?
On a managed platform, the platform's core software and the runtime under it are maintained by the platform's operator. You don't open a ticket for each site. At WebinOne this shows up on the public system status page, where platform releases are announced and rolled across sites by our team. For this specific pair of vulnerabilities, our status note of October 22, 2026 said that "the WebinOne platform is built on .NET, not PHP, so our core application (CMS platform, Portal, SSO) is not written in the language these particular vulnerabilities target."
Moving doesn't take everything off your desk. Custom integrations, third-party scripts and who has access to each site remain the agency's responsibility on any platform. What changes is the size of the job: the per-site runtime inventory, the host-by-host questions and the branch-upgrade calendar stop being yours.
Moving a site is a rebuild, not a file copy, which is why the order matters. Patch everything first, under no time pressure from a migration. Then take your list of sites on PHP 8.1 or older, plus those on 8.2 facing the December cut-off, and treat it as a shortlist of candidates for migration. Our guide to migrating a portfolio of websites covers scoping and pricing that work.
Where should an agency go from here?
If your inventory turned up a group of client sites you'd rather not keep running PHP upgrades for, two routes fit:
- Join the WebinOne partner program. Partners run client sites on WebinOne under their own brand, with white-labeling, and direct billing is available.
- Hand the moves to TeamOne, the WebinOne team that delivers migrations and builds for partner agencies. Its Migration Package rebuilds an existing WordPress or other-platform site on WebinOne, so your team can stay on client work.
Either way, patch first. The checklist above is what keeps your clients covered this month. The migration decision is about how many more of these advisories you want to handle one site at a time.
