PHP2Shell for agencies: client triage and evidence list

To triage client sites for PHP2Shell (CVE-2026-109618 and CVE-2026-109619), list every domain, group the sites by who controls the PHP runtime, and collect one piece of evidence per site: the fixed package or build name plus a restart or redeploy time after it. A version banner, a panel label or a host's reassurance is not evidence.

Which client sites do I check first?

Every site that serves PHP, which means every WordPress, WooCommerce, Magento, Shopware, Drupal and Laravel client, plus anything a builder generated on a PHP host. The bug sits under the application, so plugin updates close nothing. The full scope of affected PHP builds is laid out separately.

The UK NCSC asks for an inventory first, covering every PHP install, old or new, internet-facing systems first. CERT-EU says end-of-life branches are affected too. The Canadian Cyber Centre adds that appliances, applications and containers can bundle PHP without anyone calling it PHP. For an agency that means staging copies and forgotten microsites as well as the main sites.

Within that list, start with stores and sites holding personal data, then end-of-life PHP, then the rest. PHP 8.2 reaches end of life on 31 December 2026, per the PHP notice, so a site pinned to 8.2 has a second reason to move.

How do I group client sites so the right person gets asked?

Group by who can change the PHP runtime, because that person owns the evidence. Our responsibility guide explains the layers.

Two traps recur. A cPanel server can assign a different PHP version to each domain, so one host answer can be true for one client and false for the next. And a managed host that resolved an incident has not necessarily told you anything about your site: Kinsta's status note marked the rollout resolved on 22 October at 08:26 UTC but published no per-site build or restart time, as we set out on the Kinsta page. At WP Engine we found no dated PHP2Shell note at all, so that status is unknown.

What counts as evidence for one client site?

Keep a ledger with one row per domain. A row is complete when it answers "can you prove it?" without a phone call.

• Domain, client, host, and the person who can change PHP.
• The PHP handler and which PHP version the domain uses (for the domain itself).
• The package, build or image identifier, and where the changelog or build log names both CVEs.
• The restart or redeploy time, which must be later than the install time.
• Who said it, on what date, and the message itself saved with the row.
• State: detected, unknown, or confirmed by owner evidence (defined below).
• Date the client was told, and what they were told.

A client's scanner says a patched site is vulnerable. Who is right?

Often the scanner is reading a banner. Debian's security FAQ says it backports fixes into the version it shipped, so a package can carry the old number and still hold the fix. Plesk's change log records the fix backported on 21 October to PHP 8.1.34, 8.0.30 and 7.4.33 on Linux, with those numbers unchanged. Canonical lists 8.1.2-1ubuntu2.28 as the fixed package on Ubuntu 22.04.

A banner can be wrong in the other direction too. A site that hides its version, or sits behind a proxy, shows nothing, and a package that was updated but never restarted still runs old code. Canonical says the application likely needs a restart or the system a reboot, and watchTowr's FAQ gives the same instruction to restart workers.

So when a client forwards an alert, answer with the ledger row. Send the package changelog or build record and the restart time, and ask the scanner's operator to retest against that evidence. If the row is empty, ask the host.

What do I send a host that says "we are on PHP 8.3"?

A branch number answers nothing. Send this, per domain, and save the reply. Our shared hosting page has the longer version.

For [client domain], which PHP build serves web requests, and does its package changelog name CVE-2026-109618 and CVE-2026-109619? Please give the build or backport identifier, the date and time the workers serving this domain were restarted or replaced, and whether we need to redeploy or change a setting. Please reply in writing so we can forward it to our client.

Read the answer against this table.

If a host cannot confirm, the interim settings in the PHP notice reduce exposure and do not replace the update: session.upload_progress.enabled=0 set where it applies before request parsing, then every worker restarted. Test an upload and a checkout afterwards, since changes to request handling can break both.

What do I tell the client?

Say what you can show, with a date, and say what you are waiting for. Avoid "we patched PHP immediately" unless the row backs it, because it draws a request for proof. Ready-made client email templates cover other situations too.

Update on [domain], [date]. PHP, the language your site runs on, had two serious flaws disclosed on 21 October. Status for your site: [confirmed: your host confirmed in writing on (date) that the fixed build is serving your site and was restarted at (time) / unknown: we have asked your host to confirm the fixed build and restart time and expect a reply by (date)]. We will write again when that changes. We are also reviewing logs from 17 October for signs of earlier activity.

For clients with a smaller site and no technical contact, the ten minute response page is written for them and can be forwarded as is.

Were client sites hit before we patched?

Start the look-back at 17 October, four days before disclosure. AWS recorded its first honeypot attempt that day and advises starting review from at least then. AWS also says it is unclear whether any attempt would have worked on a real system, and its listed addresses are shared infrastructure to investigate rather than block. watchTowr reports its own honeypot attempts from 21 October. All of that is vendor telemetry.

The government position is cautious. The Canadian Cyber Centre said in its 23 October update that it had not identified active exploitation, and warned that could change quickly. No primary source we read names a compromised client site, so do not tell a client that theirs was or was not hit. Tell them the window you checked and what you looked at.

For each exposed site, look at the web server and PHP logs for the window, unexpected PHP files in upload directories, new administrator accounts, scheduled tasks you did not create, and unfamiliar outbound connections. If anything looks wrong, preserve logs before you clean, and rotate credentials the PHP user could read. Deleting one odd file does not end an investigation.

One separate incident overlaps the dates. TeamUpdraft says unauthorised access to its customer database included UpdraftCentral connection keys, and released UpdraftPlus 1.26.13 and 2.26.13 on 19 October. Its notice does not tie that incident to PHP. If you manage client sites through UpdraftCentral, handle it as its own checklist, alongside this one; the wider risk of agency management plugins is covered separately.

May I scan or touch a client site?

Get the client's written agreement first, and keep two permissions apart: checking and changing. If a site is later hacked, who carries the liability depends on your contract. A domain owner can prove control of a domain, but that does not mean your client has agreed to what you plan to do on their host account.

On the Red side, the free scan reads the stack a site serves and matches each version to known vulnerabilities, one scan per domain. You prove ownership by adding one DNS TXT record, so the client or whoever holds their DNS has to do that step. It is a lookup. It can say a version is affected. It cannot say whether a given setup is exposed, see a vendor backport, which runtime serves a virtual host, or whether workers restarted. Use it to find sites where the banner already looks old. Do not use it as a clearance. A full scan costs $100 per scan and is ordered from the dashboard once the free scan has run.

What is the order of work this week?

• Today: build the ledger from your hosting accounts, billing list and DNS. Mark each site's controller. Send the host question for every managed and shared site.
• Today: patch and restart the servers you administer, then record the package and the service start time.
• Within 48 hours: send each client a dated status in the three-state wording. Chase hosts that have not replied.
• Within 48 hours: start the look-back from 17 October on stores and sites holding personal data.
• This week: decide, with each client, what happens to sites on end-of-life PHP with no vendor backport: move, or accept a documented interim.
• This week: schedule 8.2 sites to move before 31 December 2026.

More agency guidance is on the agency and MSP security pages. The wider picture is in the October 2026 tracker. Server-side steps are in the fix and verify guide.