Agency Client Site Security Incident: October 2026 Guide

For an agency, the October 2026 incident that reaches every PHP client site is PHP2Shell (CVE-2026-109618 and CVE-2026-109619), two remote code execution flaws in PHP itself. The fix is a patched PHP build (8.5.12, 8.4.27, 8.3.36, 8.2.35 or a vendor backport) plus a worker restart, for each site. Get that confirmed in writing before you tell a client "patched". The agency triage and evidence list shows what to keep per site.

Which client sites are in scope?

Every client site that runs on PHP. That covers WordPress, WooCommerce, Magento, Shopware, Drupal, Joomla and Laravel builds. The PHP project's notice says all PHP installations serving web requests are at risk, and calls mod_php the highest-risk setup. Static sites, Node.js apps and hosted stores that run no PHP of yours are outside this bug. Node.js shipped its own security releases (22.23.4, 24.22.1 and 26.12.1) on or shortly after 21 October 2026, per the Node.js project's notice as shown at our check on 28 October 2026.

The UK NCSC's alert starts with inventory: find your PHP systems, internet-facing ones first. It also tells you to watch vendors whose products bundle PHP. For an agency that means the client's host, any staging server, and any container image you built and still deploy.

For the wider picture, the month's full incident list lists every incident with its fix. The PHP bug's version detail is on its own page.

Why is "we updated WordPress" the wrong answer to a client?

The flaws are in the PHP engine, so application updates do not close them. The fix lives on the server. On shared and managed plans that server is the host's, not yours. On a VPS you manage, it is yours.

A backport makes a status hard to state per site:

1. Backports keep the old version number. A fixed package can still report an older version. The PHP project itself says vendors provide backported fixes for 8.1 and older. A version string alone does not prove a fix, and it does not disprove one.

That is why a client-ready line needs the build or package identifier and a restart time, not just a version. Responsibility is covered in who is responsible for patching a website.

How do I fix it across client sites?

If the client's host manages PHP

Send each host this question, once per domain, and keep the reply with the client file:

For [client domain], is the PHP runtime that serves web requests patched for CVE-2026-109618 and CVE-2026-109619? Please give the fixed package, build or backport identifier, confirm that all PHP workers serving it have been restarted or replaced, and say whether I need to redeploy or change a setting.

• List every client site by host, plan type and PHP handler
• Send the question above to each host, with the date you sent it
• Record the reply: package or build, restart time, who answered
• Chase any site with no reply, and mark it "unknown", not "patched"
• Test key pages and checkout after the host changes anything

Host-specific dated statuses are on the shared hosting page.

If you manage the server

• Update PHP from your distribution or vendor and check the package changelog names both CVEs
• Restart PHP-FPM or Apache so the running workers use the fixed build
• Rebuild and redeploy any container image that bundles PHP
• Repeat per virtual host if more than one PHP version runs
• If you cannot patch yet, the PHP project lists partial mitigations and says only an update is a complete solution. The UK NCSC says to consider taking the system offline if mitigation takes too long

Am I affected? Where each client site stands

Was anything exploited, and what should I look for?

CISA added both CVEs to its Known Exploited Vulnerabilities catalog on 26 October 2026, with a federal due date of 29 October and a forensic triage flag on each entry. AWS says its honeypots recorded attempts before the public disclosure, and also says it is unclear whether they would have worked on real systems. That is vendor telemetry. The UK NCSC alert does not say the flaws are being exploited. We found no first-party report of a confirmed compromise of a named site at our check on 28 October 2026.

The KEV listing means exploitation is confirmed to CISA's standard, so treat any unpatched PHP site as a priority. "Attempts" is not "compromised". Say attempts for attempts, and use "compromised" only with evidence from that site. The NCSC advises checking for signs of compromise and backdoors where you cannot update or disable a system immediately.

What about the UpdraftCentral incident?

It is a separate event with a different cause (the site-owner version of these steps is on its own page), and it touches WordPress client sites that use UpdraftCentral. TeamUpdraft says it identified unauthorised access to its website over the weekend of 17 to 18 October, and that the customer database, including UpdraftCentral connection keys, was believed accessed. Its 21 October update also asks UpdraftPlus Premium users to check their sites for compromise even if they have never used UpdraftCentral, and its 22 October update flags unexpected Editor roles (at our check on 28 October 2026). Patchstack says there is no CVE, because it is a key compromise and not a code flaw.

TeamUpdraft's published order, per site, from its notice last updated 23 October (at our check on 28 October 2026):

1. Log in to the site's own WordPress dashboard, not through UpdraftCentral.
2. Update UpdraftPlus to 1.26.13 (free) or 2.26.13 (Premium), or later.
3. Disconnect the site and delete the UpdraftCentral connection key.
4. Check Users for administrator accounts you do not recognise, and remove them.
5. Check Plugins, including must-use plugins, for ones you do not recognise, and remove them.
6. Change the passwords of all administrator accounts.
7. If anything looks suspicious, consider a backup from before 17 October.
8. Reconnect the site to UpdraftCentral.

Patchstack warns that the backdoor creates an account that shows as an Editor and is granted manage_options and install_plugins, so reviewing your administrator list misses it, and the account stays in WordPress after the plugin is removed. TeamUpdraft's step 4 names administrator accounts; its 22 October update also flags unexpected Editor roles. On each site, check Editor accounts you do not recognise as well, and remove them.

Patching PHP does not touch this one, and updating UpdraftPlus does not patch PHP. Check each client site for both. It is also worth knowing how to find plugins that store remote-control keys before the next vendor incident.

What do I tell clients?

Keep it dated and per site. Ready-made wording is in the client email templates. A workable shape:

• What happened: PHP published two critical fixes on 21 October.
• What we did: asked the host on [date], received [package or build] on [date], or still waiting.
• What we cannot see: whether anything got in before the fix. We are looking at logs and files from 17 October.
• What we need from you: a decision on a maintenance window, and written consent for any testing.

Do not give a client a blanket all-clear, and do not name another business as a victim. A passive check and the public record support neither.

What can a scan tell me about a client portfolio?

Red by run.cloud has a free scan and a full scan. The free scan identifies the technologies a site serves, then looks each version up in public vulnerability records. It is a lookup: it can say a version is affected, not whether your setup is exposed, and it cannot see a vendor backport or a worker restart. It is one scan per domain, so a portfolio means running it domain by domain.

Permission to test client sites and the other agency guides go further. Before any scan, you add a DNS TXT record so nobody can point Red at a site that is not theirs. For a client domain, get the client's written agreement first. Domain control does not by itself authorise testing the host or any other service on the same infrastructure.