The agency guide to PHP2Shell: triaging dozens of client sites, with go/no-go decisions

The short answer

Triage client sites by who controls the PHP runtime, not by client size. Sort every site into one of four lanes: hosts that patched for the client, servers you run, servers someone else runs, and end-of-life PHP. Gather evidence for each site, then make one of four calls: GO, MITIGATE, PATCH or OFFLINE UNTIL FIXED. Do servers you control first, then Apache mod_php setups, stores and sites with logins. Record each decision with a timestamp, and send each client a one-page status. Never give a client a blanket all-clear. Tell them what’s true, as of when, and what’s still open.

Why per-site calls beat one fleet-wide decision

The two blanket options both fail. Taking every client offline costs real revenue, and clients push back. Waiting for patches means leaving exposed sites exposed. Most fleets are a mix. As of October 23, 2026, many shared and managed hosts had reported patching PHP for customers on their managed plans, while nobody patches PHP on VPS and self-managed servers for their owners (source: GoDaddy). A site-by-site call lets you take down only what needs to come down.

Speed matters because known flaws get exploited fast. According to Patchstack, a WordPress security vendor, the median time to mass exploitation for the most heavily exploited WordPress flaws was 5 hours (source: Patchstack). For PHP2Shell, Amazon saw the first exploitation attempts on October 17, four days before the fixes were released (source: BleepingComputer). As of October 23, 2026, no successful compromise had been publicly confirmed, apart from a single report by Palo Alto Networks’ Unit 42 that hadn’t been independently corroborated (source: Beazley Security Labs).

Step 0: confirm your authority, site by site

Only check and change sites your client has authorized you to work on, in writing. Where a client’s hosting is run by a third party, the decision about that server is theirs. Your job is to ask for evidence and pass it on. Don’t scan sites you don’t manage.

Step 1: build the inventory

One row per site. These columns are enough for every decision below:

client, domain, host_and_plan, who_manages_php, php_branch_serving_site,
how_php_runs (FPM | mod_php | LiteSpeed | other), cms_or_framework,
store_or_logins (y/n), staging_copies, evidence_level, decision,
decided_at_utc, client_contact

Two cautions. First, record the PHP that serves each site, not the command-line version. Second, the version number tells you the branch, not whether it’s patched (source: AlmaLinux).

Step 2: sort into lanes by who patches

Step 3: prioritize

Work through the fleet in this order:

1. Lane B servers without patch evidence. They’re yours, and nobody else will patch them (source: GoDaddy).
2. Apache mod_php setups, which researchers rate the highest-risk configuration (source: Beazley Security Labs).
3. Stores and sites with logins. One of the flaws can leak memory that may include passwords, session tokens and API keys (source: The Hacker News). Magento stores have lagged on patches before: researchers at Sansec found that 62% of Magento stores were still vulnerable six weeks after the SessionReaper flaw was disclosed (source: The Hacker News).
4. Lane D sites with no backport.
5. Lane A and C sites, where your job is to chase written confirmation.

Step 4: make the go/no-go call

The OFFLINE call follows public guidance. The UK NCSC advises that if temporary mitigations can’t be applied in time, “you should consider taking the system offline until it can be fully mitigated.” (source: UK NCSC) CISA and CERT-EU gave similar advice for systems that can’t be patched (source: CISA; CERT-EU). When a site goes offline, use a proper maintenance page. Don’t switch off PHP handling on the server, which can expose source code to visitors (source: Beazley Security Labs). The client decides when the site comes back. Give them the evidence to decide with.

Step 5: collect the evidence

For every GO and PATCH, keep a per-CVE record with a timestamp and an evidence level. Our guide to proving a patch covers the five checks and the four evidence levels. Version headers and scanner results are level 4: fine for sorting the fleet, never proof (source: AlmaLinux). Clients with cyber insurance will want the same records; here’s what to keep.

Step 6: check exposed sites for signs of compromise

Any site that ran unpatched PHP since October 17 needs a compromise check, because attempts began before the patch (source: BleepingComputer). Look for unfamiliar files, new admin accounts, new scheduled tasks and anything unusual started by the web server. Remember PHP’s own warning: “absence of an error in logs is not proof of safety.” (source: GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)) Where a site was exposed, rotate admin and database passwords, API keys and tokens (source: The Hacker News). If you find indicators of compromise, stop. Preserve the evidence, tell the client, and bring in incident response before changing or deleting anything.

Step 7: tell each client, in one page

Clients need a decision, not a lecture. A template:

Subject: [Client] website: PHP security status as of [date, time UTC]

Site: [domain] · Hosting: [managed host / our server / your server]
Decision: [GO / MITIGATE / PATCH / OFFLINE UNTIL FIXED]

PHP2Shell (CVE-2026-109618, CVE-2026-109619): [patched via fixed release /
  backport named in vendor changelog]; PHP restarted [date]. Evidence level [n].
CVE-2026-115560: no PHP fix released as of [date]. PHP's recommended
  setting [applied on (date) / scheduled for (date)].
Compromise check since 17 October: [no evidence of compromise found in the
  checks listed / not yet done / not in scope].
  Checks run: [list]. Data we couldn't see: [list].
What we need from you: [approval for a maintenance window / nothing].
Next: PHP 8.2 stops receiving security fixes on 31 December 2026. Your site
  runs PHP [x.y]. [Our upgrade recommendation and date.]

Keep the wording exact. “No evidence of compromise found in the checks listed” is accurate. A blanket promise that nothing got in is one nobody can keep.

Step 8: plan the PHP 8.2 wave now

The next deadline is December 31, 2026, when PHP 8.2 stops receiving security fixes (source: php.net supported versions). WordPress.org’s statistics (as of October 24, 2026) show about 58% of WordPress sites run PHP 8.2 or older (source: WordPress.org statistics). If your portfolio looks like WordPress overall, most of your clients need an upgrade this quarter. Use the inventory you just built. Group sites by host and stack, and upgrade the switch-ready ones first. Schedule store clients before their holiday code freeze around Black Friday and Cyber Monday. The 8.2 checklist has the steps.

Common mistakes to avoid

• Assuming a VPS client was patched because the host patched its shared plans (source: GoDaddy).
• Trusting php -v, a version header or a scanner as proof (source: AlmaLinux).
• Patching without restarting PHP, so the old code keeps running (source: AlmaLinux).
• Forgetting staging copies, old sites and scheduled PHP jobs.
• Leaving out CVE-2026-115560 because “we already patched” (source: php.net advisory on CVE-2026-115560, October 23, 2026).
• Treating a firewall as the fix (source: Beazley Security Labs).
• Promising clients a finished, no-risk status in writing. As of October 23, 2026, CVE-2026-115560 alone makes that untrue (source: php.net advisory on CVE-2026-115560, October 23, 2026).

Sourced facts

Full wording, primary sources and dates: /sources.

Frequently asked questions

A client’s host says they patched. Can I mark the site GO?

Only with written confirmation that covers the client’s account and both CVEs, gives a date, and addresses the CVE-2026-115560 setting (source: php.net advisory on CVE-2026-115560, October 23, 2026). A general status page is a start, not a record. Use our host questions and email.

A client refuses to take an exposed site offline. What do I do?

Write down your recommendation, the evidence and their decision, and mitigate as far as you can in the meantime. The decision is theirs; your record shows you gave them what they needed to make it.

How long can a site stay on MITIGATE?

Only until the patch deadline you set. Firewalls can buy time, but attackers changed payloads to get past firewall rules within hours (source: Beazley Security Labs). Treat MITIGATE as a bridge with a date on it.

Want a partner for the fleet?

• Agency Fleet Triage. We work through steps 1–5 across your client list, read-only: public checks, your hosts’ written confirmations, and read-only access to the servers you manage: a dedicated login that can look but not change anything, shared through a secure link, never by email. We change nothing on any server. You get a per-site GO / MITIGATE / PATCH / OFFLINE UNTIL FIXED call, approved by a named person, with a client-ready one-pager for each site and a fixed-price quote for every site that isn’t GO. Every client signs their own authorization. Talk to us
• Partner program. Resell or co-deliver our fixed-price work for your clients. We partner with agencies, not against them. Partner details