PHP2Shell for Agencies Managing Many Client Sites: A Fleet Playbook

As of 23 October 2026, the PHP2Shell flaws (CVE-2026-109618 and CVE-2026-109619) are fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, exploitation attempts are widely reported, no confirmed successful compromise is publicly documented, and neither CVE is on CISA's Known Exploited Vulnerabilities list. For an agency with dozens or hundreds of client sites, the work is a fleet operation. Inventory every PHP runtime, patch in risk order, verify the build that actually serves each site, tell clients what you did, and make clear who owns which part.

The unit that matters is the PHP runtime, not the website. One server can host forty client sites on one PHP-FPM pool. One client can have a production site, a staging copy and a forgotten campaign microsite on three different hosts. Count runtimes, and you will find the gaps a site list hides.

This playbook is for agency owners, account managers and the developers doing the work. For the technical detail behind each step, see our fixed versions guide and restart guide.

Step One: Build a Runtime Inventory

ENISA's joint statement sets the order: "identify their PHP-based applications, coordinate with hosting and service providers, and apply the released security updates. Prioritise internet-facing systems." CISA adds a warning that fits agencies well: "PHP is often a component of other software and prevalence may not be directly observable." A spreadsheet is enough. Capture these fields for every runtime:

Don't stop at your hosting accounts. Check client-owned hosting, staging environments, preview servers, old campaign sites, and any container images in your build pipeline. Our guide on how to check a PHP version covers reading the web-serving build on each setup.

Step Two: Patch in Risk Order

When you can't do everything at once, PHP's own advisory and the government alerts give a defensible order:

1. Internet-facing mod_php. PHP's advisory says: "We consider the risk highest for mod_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs." Docker's official php:*-apache images use mod_php, so check containerized client sites too. See our Apache mod_php guide.
2. PHP 8.1 and older. No official release exists, only source backports and vendor packages. CISA says organizations that "continue to use PHP 8.1 or earlier unsupported versions, should take PHP-based systems offline until they can be patched or updated." Get a patched distribution or paid support build, or isolate the site.
3. Runtimes you manage directly. VPS, dedicated and cloud servers, and custom containers. No host will patch these for you. Several hosts and cloud providers say so explicitly, for example Google Cloud: "Container images you build yourself are your responsibility."
4. Other self-managed setups. PHP-FPM, LiteSpeed and FrankenPHP servers. They are all in scope per php.net, and each has its own restart rules.
5. Managed hosting. Most large managed hosts say they patched without customer action. Collect written confirmation per account, then move on.
6. Internal and low-traffic sites. Staging, previews and old microsites. They are low priority only if they are not reachable from the internet. Most are.

On every server you touch, set session.upload_progress.enabled=0 in php.ini or the FPM pool. PHP advised on 23 October 2026 to keep it off until the next regular release because of CVE-2026-115560, which affects patched builds too. Our interim mitigations guide covers the other settings and what they break.

Step Three: Verify at Scale

A fleet is only as patched as its least-checked runtime. For each row of the inventory, record proof, not assumptions:

• Package changelog or build date. Linux distributions backport fixes without changing the version number. Red Hat warns that "just looking at the version number of a package will not tell them if they are vulnerable or not." On Debian and Ubuntu, apt-get changelog shows the entry. On CloudLinux and other RPM systems, search the package changelog for the CVE IDs.
• The web-serving PHP. The command-line php binary can be a different version from the one PHP-FPM or Apache runs. Check through the web server.
• Process start times. Confirm PHP processes started after the update was installed.
• The new directive, with care. Official 8.2.35 to 8.5.12 builds add memory_hard_limit_percent. PHP's manual says that if it isn't recognized, the PHP in use is affected. That test is reliable only for official upstream builds. The 8.1 backport doesn't add it.
• Host answers in writing. For managed accounts, file the host's reply with the inventory row.

A Client Communication Template

Clients will ask. A short, factual note sent before they ask builds trust. Avoid saying a site "is safe" or "was not affected" unless you can prove it. Say what was checked and confirmed. Adapt this example:

Subject: PHP2Shell security update for [site address]
Hello [name],
On 21 October 2026 the PHP project fixed two critical flaws in PHP, the software that runs your website's server (CVE-2026-109618 and CVE-2026-109619). The fix is a server update. Updating [WordPress / Drupal / your CMS] does not fix it.
What we did: [On (date), we confirmed with (host) / we installed] a patched PHP build for your site and confirmed PHP was restarted. Evidence: [changelog entry / build date / host confirmation].
What we checked: [admin accounts, recent file changes and logs from 17 October onward]. [We found no signs of compromise / We found (finding) and have (action)].
What we need from you: [nothing at this time / approval for (action) / hosting login for (account)].
Next steps: [planned PHP upgrade before 31 December 2026 / none].
[Your name]

For clients on hosting you don't control, change "What we did" to what you asked the host and what they replied.

Who Owns Patching: Contracts and Shared Responsibility

PHP2Shell will expose every vague maintenance contract. A runtime that the agency thinks the host patches, the host thinks the client patches, and the client thinks the agency patches will stay unpatched.

The joint Five Eyes advisory on managed service providers, AA22-131A, is a useful baseline. It tells customers to "ensure MSP-customer contracts transparently identify ownership of ICT security roles and responsibilities" and that "contractual arrangements specify that their MSP implements these measures and controls." Host terms set the other edge. Kinsta, for example, says: "You are responsible for installing, updating, and removing any plugins and themes on your WordPress site." Most hosts state a similar split. Our shared responsibility guide maps it out.

Some clients' regulators reach their service providers, and that includes their web agency:

• The FTC Safeguards Rule requires covered financial institutions to oversee service providers, including "requiring your service providers by contract to implement and maintain such safeguards" (16 CFR 314.4).
• The SEC's amended Regulation S-P requires covered firms to make sure their service providers notify them "no later than 72 hours after becoming aware" of certain breaches (Federal Register).

If you serve financial, health or legal clients, check what your agreements promise. This is general information, not legal advice.

Logs, Evidence and Suspected Compromise

Patching closes the door. It doesn't tell you whether anyone came in. Before restarting or rebuilding a server that looks suspicious, Beazley Security advises: "Preserve web, PHP, application, and host logs before restarting or rebuilding a suspect system." Look back to at least 17 October 2026, the date of the earliest attempt Amazon reported. AA22-131A also recommends that organizations "store their most important logs for at least six months."

Clean error logs are not proof. PHP's advisory says "absence of an error in logs is not proof of safety," and Bitdefender notes a successful exploit "can return HTTP 200 and leave the worker running." If you find signs of compromise on a shared server, treat every site on that runtime as affected. Rotate the secrets the PHP process could read, such as database passwords, API keys and cloud credentials. Our "was my site hacked?" guide lists the signs to check.

After the Emergency: Shrink the Fleet's Risk

• Retire EOL PHP. Every runtime on 8.1 or older depends on backports from someone else. Schedule upgrades now.
• Plan for 31 December 2026. PHP 8.2 gets no security fixes after that date. Sites moved to 8.2 this week will need another move soon.
• Standardize. Fewer PHP branches, server APIs and hosts make the next emergency faster. Our patching best practices guide covers routine patch cycles.
• Keep the inventory. Update it whenever a site launches, moves or closes.

Conclusion

For an agency, PHP2Shell is a test of how well you know your own fleet. The fix is the same on every server: a patched PHP build and a restart. What separates a calm week from a bad one is a runtime inventory, a sensible patch order, proof of each fix, plain communication with clients and contracts that say who owns what. If you need extra hands on a large or mixed fleet, our emergency PHP patching team can work under your direction. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions