PHP2Shell for Agencies and MSPs: A Client Fleet Playbook

PHP2Shell (CVE-2026-109618 and CVE-2026-109619) lets one unauthenticated request run code on servers running PHP, and agencies and MSPs often hold the keys to dozens or hundreds of them. Build a client inventory today, patch mod_php and end of life PHP first, tell every client where they stand, and keep evidence of each fix.

For background on the bugs, read our explainer on PHP2Shell, CVE-2026-109618 and CVE-2026-109619. For the commands that patch one host or image, see how to find and patch every PHP runtime. This post covers what those two do not: you answer for a hundred sites built different ways, on hosts you do not all control, under contracts that say different things.

What happened, from a service provider's seat

These are the events that changed what agencies and MSPs had to do on 20 and 21 October.

Exploitation status is disputed. Cloudflare wrote that it "observed attack traffic targeting our customers," while Huntress had not seen it among its partners. For a provider with many clients, that dispute changes little: you cannot wait to learn which sites get hit first.

Your clients may also have read about public bodies taking sites offline as a precaution, which we cover in governments taking websites offline over PHP2Shell.

Why this one lands on agencies and MSPs

A typical agency CVE is a plugin, and a care plan with auto updates handles it. PHP2Shell sits below that. Cloudflare's post is plain about it: updating site code or plugins does not fix a flaw in the PHP runtime. So the question for every client becomes "who controls the PHP binary, and have they changed it and restarted it?"

The answer differs by setup.

Google Cloud's guidance shows the split cleanly. App Engine standard apps on PHP 8.2 or newer update automatically, App Engine flexible apps must be redeployed, and the company says "Container images you build yourself are your responsibility." Most hosting relationships have the same shape, even when nobody wrote it down.

Hour one: build the client inventory fast

You will not have a perfect asset register. You can have a good enough one in an hour by working from several directions and merging the results into one sheet.

1. Start from billing, not memory. Export every active client from billing or your PSA, plus every domain whose DNS you manage. Include clients you think are "not ours to patch," and forgotten staging and demo sites, which are usually public and rarely updated.

2. Fingerprint from the outside. PHP's expose_php setting defaults to on and puts the version in an X-Powered-By header, according to the PHP manual. A loop gives you a first pass.

# domains.txt: one client hostname per line
while read -r d; do
  h=$(curl -sI --max-time 10 "https://$d/" | tr -d '\r' | grep -i '^x-powered-by:' | cut -d' ' -f2-)
  printf '%s,%s\n' "$d" "${h:-unknown}"
done < domains.txt > php-headers.csv

Treat this as leads only. Many hosts hide the header, CDNs can strip it, and distro builds with a backported fix still report an old upstream number. "Unknown" never means safe.

3. Ask the panels. On cPanel with EasyApache 4, WHM's API lists installed PHP versions and which virtual hosts use each, per cPanel's API docs and hosting knowledge bases that script against them.

whmapi1 php_get_installed_versions
whmapi1 php_get_vhost_versions                     # every vhost and its PHP version
whmapi1 php_get_vhosts_by_version version=ea-php81 # who is still on 8.1

On Plesk, the CLI lists handlers and the domains using each one:

plesk bin php_handler --list -json true
plesk bin php_handler --get-usage -id <handler-id>

Tools that let each hosting user pick their own PHP version can make panel reports incomplete, so spot-check a few accounts.

4. Sweep the servers you can reach. For hosts you manage over SSH, run one read-only collector and save a file per host.

mkdir -p inventory
# hosts.txt: one SSH target per line, for example deploy@web01.example.net
while read -r h; do
  ssh -n -o BatchMode=yes -o ConnectTimeout=10 "$h" '
    echo "host: $(hostname)"
    for b in /usr/bin/php /usr/bin/php[0-9]* /usr/sbin/php-fpm* /usr/local/bin/ea-php* /opt/plesk/php/*/bin/php; do
      [ -x "$b" ] && printf "%s: %s\n" "$b" "$("$b" -v 2>/dev/null | head -n1)"
    done
    (apachectl -M 2>/dev/null || httpd -M 2>/dev/null) | grep -i php
    ps -eo comm | grep -E "php-fpm|php-cgi|lsphp|frankenphp" | sort -u
  ' > "inventory/$h.txt" 2>&1
done < hosts.txt

A php line in the Apache module list means mod_php is loaded, which moves that host up the queue.

5. Use wp-admin where you have nothing else. In WordPress, Tools, then Site Health, then Info has a Server section with PHP details, and WordPress's docs note the Info tab can copy everything to the clipboard. Paste it into the ticket.

6. Read the repos. If you build client code, the repos show which projects ship their own PHP and which are pinned to old branches.

grep -rHE '^FROM\s+php:' --include='Dockerfile*' ~/clients/
grep -rHE '"php"\s*:' --include=composer.json --exclude-dir=vendor ~/clients/

A constraint like ^7.4 does not tell you what runs in production, but it does tell you that moving to a supported branch is a project, not a toggle.

7. Merge into one sheet. Useful columns: client, site, host, who controls PHP, branch, SAPI, internet-facing, ecommerce or login, contract type, contact, status, evidence link.

Triage order

You cannot patch a hundred sites at once. The advisories give you a defensible order.

Finding the .htaccess cases on a shared server takes one command:

sudo grep -rlE '^\s*php_(value|flag|admin_value)' --include=.htaccess /home /var/www 2>/dev/null

The 2022 joint advisory on managed service providers from CISA, the UK NCSC and partner agencies says to put known exploited vulnerabilities first. Here the exploitation evidence is mixed, so rank by exposure: who can reach the PHP, and what the site holds.

Patching at fleet scale

Per-host mechanics are in our find and patch post. At fleet scale the work is batching and verification.

1. Group by patch path, not by client. cPanel servers update one way (ea-phpNN packages through the OS package manager), Debian VPSes another, images on php:8.3-fpm a third. Ten clients on one path is one procedure run ten times.

2. Canary first. Patch two or three low-risk sites per path, restart, load a page and submit a form, then roll the rest. A broken site in wave one costs minutes; a broken fleet costs a weekend.

3. Restart every worker. PHP's mitigation notes call for restarting every worker, and Mattias Geniar's guide warns that "A reload is not enough." Include queue workers and other long-running PHP processes.

4. Set interim mitigations at server level, never per site. PHP tells hosts to make sure .user.ini, per-directory config or ini_set() cannot override pool or server settings. One tenant's .htaccess should not undo your fix.

5. Run end of life sites as a separate track. Forcing a 7.4 site onto 8.2 can break it. Reclaim Hosting moved its managed 8.1 and older sites to 8.2 and told customers to check their sites afterwards. If you do the same, warn the client, snapshot first, and test checkout and forms. PHP 8.2 itself reaches end of life on 31 December 2026, per php.net, so aim for 8.3 or newer where the code allows.

6. If you cannot patch tonight, isolate. A CDN maintenance page, access limited to the client's office IP, or a mode that rejects everything except GET and HEAD (an interim option both Sansec and Geniar list) all keep a site off the attack path without deleting anything. Sansec warns that Magento and WordPress maintenance modes do not help, because PHP parses the request first.

Client communication templates

Send the first notice before you know everything. Clients who hear about PHP2Shell from the news before they hear from you will remember it. Keep the tone flat, and do not promise what your contract does not cover.

First notice, same day, to every client:

Subject: PHP security issue (PHP2Shell): what we are doing for your site

Hi [Name],

Two critical flaws in PHP, the language that runs [site], were fixed on
21 October (CVE-2026-109618 and CVE-2026-109619). They are in PHP itself,
not in WordPress or your plugins, so normal site updates do not fix them.

We are checking which PHP version your site runs and who is responsible
for updating it. By [time] you will hear one of three answers: already
patched, patched by us today, or action needed from you or your host.

If you have a separate IT team or host, please forward this to them.

[Your name], [Agency]

To a client's hosting provider, when you do not control PHP:

Subject: PHP2Shell (CVE-2026-109618, CVE-2026-109619): status for [domain]

Hello,

We manage [domain] on account [account ID]. Please confirm in writing:

1. The PHP version and SAPI serving this site, or the package version
   whose changelog includes both CVE fixes.
2. When PHP workers were restarted after the update.
3. If the site runs PHP 8.1 or older, your plan and date for a fix.

Thank you,
[Name], on behalf of [Client]

Done, with evidence:

Subject: PHP2Shell: [site] is patched

Hi [Name],

[Site] now runs PHP [version] with the fix for CVE-2026-109618 and
CVE-2026-109619. We restarted PHP at [time, UTC] and checked the site
afterwards. The evidence file is attached and stored in ticket [ID].

We also checked the server for common signs of compromise and found
[nothing / the following].

[Your name]

End of life, upgrade outside current scope:

Subject: PHP2Shell: [site] needs a PHP upgrade

Hi [Name],

[Site] runs PHP [version]. The PHP project no longer releases fixes for
it, so the safe path is PHP 8.3 or newer, which may need code changes.

Until then we recommend [restricting access / a maintenance page]. This
protects the site but [effect on visitors].

The upgrade is outside your current plan. Our estimate is [hours/cost].
Reply "approve" to start, or "isolate only" to keep the site restricted
while you decide.

[Your name]

Taking a site offline as a precaution:

Subject: [Site] is temporarily offline as a security precaution

Hi [Name],

We have temporarily [taken [site] offline / limited access to it]
because its PHP cannot be patched safely tonight. National cyber security
agencies advise this for systems that cannot be fixed quickly. No data
has been lost and we have seen no sign of a break-in.

Expected return: [time]. We will message you when it is back.

[Your name], [phone]

Who patches and who pays

This is general guidance, not legal advice. Your contract, local law and your insurer's terms decide the real answer, so read them and ask counsel where money or liability is at stake.

The 2022 joint advisory on MSPs sets a baseline. It says contracts should state whether the provider or the customer "owns specific responsibilities," how and when the provider reports incidents, and that customers should ask for timely updates delivered as an ongoing service. Few agency contracts are that precise. In practice the split usually looks like this.

Rules of thumb that hold across most of these:

• Where you clearly own the server, patch first and invoice later. Log the time and settle billing next week.
• Where ownership is unclear, get a one-line written yes. "Please patch PHP on [site] now; bill at [rate]" is enough to act on and protects both sides.
• Separate the patch from the upgrade. A fixed package on a supported branch is maintenance. Moving a site from 7.4 to 8.3 with code changes is usually project work.
• Know your notification duties. If you find signs of compromise, the contract may set a deadline for telling the client, and some cyber insurance policies require prompt notice.

Evidence of patching

Clients, auditors and insurers may later ask what you did and when. Collect proof while you patch. For each host, capture what is installed, whether the CVE fix is in the package changelog, and whether workers started after the package changed.

#!/usr/bin/env bash
# php2shell-evidence.sh: run on each host after patching; attach output to the client ticket
out="php2shell-evidence-$(hostname)-$(date -u +%Y%m%dT%H%M%SZ).txt"
{
  echo "host: $(hostname)  collected: $(date -u)  by: ${USER:-unknown}"
  echo "--- PHP binaries"
  for b in /usr/bin/php /usr/bin/php[0-9]* /usr/sbin/php-fpm* /usr/local/bin/ea-php*; do
    [ -x "$b" ] && echo "$b: $("$b" -v 2>/dev/null | head -n1)"
  done
  echo "--- packages and CVE in changelog"
  if command -v dpkg >/dev/null; then
    dpkg -l 'php*' 'libapache2-mod-php*' 2>/dev/null | awk '/^ii/ {print $2, $3}'
    for p in $(dpkg -l 'php*-fpm' 'libapache2-mod-php*' 2>/dev/null | awk '/^ii/ {print $2}'); do
      echo "$p: $(apt changelog "$p" 2>/dev/null | grep -m1 -oE 'CVE-2026-10961[89]' || echo 'CVE not found')"
    done
  elif command -v rpm >/dev/null; then
    rpm -qa --last 'php*' 'ea-php*' | head -n 10
  fi
  echo "--- running PHP and web server processes with start times"
  ps -eo pid,lstart,cmd | grep -E '[p]hp-fpm: master|[h]ttpd|[a]pache2|[l]sphp' | head -n 20
} > "$out"
echo "wrote $out"

Add the outside view by re-running the header loop and keeping the CSV. For containers, record the new image digest, the container start time and any scanner output.

For the compromise review, Huntress suggests looking for web workers spawning shells or download tools, new files in the web root, new cron jobs and new accounts. A first pass for new PHP files:

# PHP files created or changed in web roots since the leak; mtimes can be faked, so treat hits as leads
sudo find /var/www /home/*/public_html -name '*.php' -newermt '2026-10-20' 2>/dev/null | head -n 100

Expect noise from caches and plugin updates; anything new in an uploads folder deserves a closer look. If you find real signs, patching does not remove what an attacker left behind. Isolate the host, keep logs, and rotate secrets that lived on it.

Preparing for the next one

PHP2Shell gave about a day of warning. The next runtime bug may give less.

• Keep the inventory alive. Run the SSH collector and header loop nightly into the same sheet, and alert when a site lands on an end of life branch.
• Fewer patch paths. Every distinct hosting stack is another procedure. Moving clients onto two or three standard stacks is a security decision as much as a cost one.
• An end of life calendar. List every client on PHP 8.2 now and quote the move before 31 December 2026.
• Contract language before the incident. An emergency patch clause, a statement of which layer you maintain, standing permission to isolate a site, and your notification window.
• Templates and contacts on file. Keep the messages above in your helpdesk, with a named security contact per client.
• Worker process alerts. A PHP worker starting a shell is rarely legitimate, for this bug or the next.

What would have helped

Practices any agency or MSP can use

What slowed providers on 21 October was mostly not the patch. It was finding the sites, working out who was allowed to touch them, and writing the messages. An inventory with a "who controls PHP" column, contracts that name the layer you maintain, server-level settings tenants cannot override, and templates written in a quiet week turn that scramble into a checklist. Our October 2026 roundup shows the same pattern across this month's other incidents.

Where Safeguard fits

Safeguard would not have prevented PHP2Shell, and it does not patch servers or restart PHP. It helps with the part of an agency fleet that lives in repositories and images.

• Scan client repos and images. safeguard scan --dir . scans a repository, safeguard scan --image <name> builds an SBOM of a container image including OS packages such as PHP, and safeguard scan --sbom <file> checks an SBOM a vendor gives you. Results land as JSON under ./output, ready for the evidence pack.
• One question across every client project. The platform shows which projects contain a given component and version, so "which client images still ship PHP 8.1" becomes a list. Our post on SBOM incident response explains that workflow.
• Gates for the next deploy. Policies and gates evaluated in the platform can block an image that still carries a vulnerable PHP package.
• The change, with approval. The Safeguard CLI's assistant can edit a Dockerfile base tag and run the rebuild and tests with your approval under the /permissions mode you choose, and safeguard exec runs a single turn in CI. You can send that work from the desktop or phone app to a computer running the CLI and approve each command. Autonomous remediation can open fix PRs, and it is off by default.

Where it does not help: PHP on shared hosts, panels or managed platforms you cannot scan, PHP installed by hand on servers you never scan, worker restarts, blocking traffic, or detecting a break-in. Reachability analysis does not lower the priority, because the bug fires in the runtime before application code runs. Distro backports can make version matching noisy, so confirm against the vendor changelog.

Zero-Day Discovery and Gold

• Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode, and issues findings as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems.
• Gold Open Source at gold.safeguard.sh is free with no login: searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a GitHub Action for CI gates. When we checked on 21 October it did not yet list these two PHP CVEs, so use php.net and your distro tracker here, and Gold for the package dependencies in client projects.
• Gold Registry at registry.safeguard.sh is the paid tier: hardened drop-in components and container images held to zero exploitable critical or high CVEs, SLSA L3 or higher, Sigstore-signed, with evidence pages; an artifact loses its badge on regression. The habit it supports is the one that matters for an agency: pull patched, signed base images from a curated source and rebuild every client image fast.

To try Safeguard, download it and follow the CLI docs.

Common mistakes

• Counting only sites you host. Clients on their own hosting still expect you to know. List them as "host owns PHP" and send the host template.
• Treating "unknown" in the header scan as clean. Hidden headers and backports make the outside view incomplete.
• Letting a plugin auto update stand in for a fix. It changes application code, not PHP.
• Patching without a canary. One bad package across a hundred sites is a second incident.
• Setting mitigations in .user.ini or ini_set(). PHP says they apply too late.
• Forcing an end of life upgrade without warning the client. It may be right; tell them first and test afterwards.
• Skipping the restart check. A patched package with an old worker is still exposed.
• Running leaked exploit code against client sites. It may be unsafe, and maintaining a site is not permission to attack it.

FAQ

We only update WordPress for our clients. Is PHP2Shell our problem?

Partly. The fix is a PHP update, which belongs to whoever runs the server. If that is the host, your job is to tell the client and get the host's confirmation. If you run the server, it is yours.

A client's host says "we're patched." What should we ask for?

The PHP version and SAPI serving the site, or a package version whose changelog lists both CVEs, and the time workers were restarted. A version string alone can mislead on distro builds.

Can we patch a client server without asking?

If your contract makes you responsible for the server, usually yes, under its maintenance or emergency terms. If not, get a written yes first. A short email is enough and protects you if the update breaks something.

Who pays for moving a site off PHP 8.1 or older?

Usually the client, as project work, because it can involve code changes. Patching a supported branch is normally maintenance. Agree the split in writing and isolate the site while you decide.

Is Cloudflare's WAF rule enough for clients behind Cloudflare?

No. Cloudflare says customers should patch even with its rules on. Like any WAF, it only sees traffic routed through it, so an origin that accepts direct connections is still exposed.

Should we rotate client credentials?

If a server was internet-facing and unpatched, consider it. Sansec says the flaw can leak memory, including passwords, session tokens and API keys. If you find signs of compromise, rotate everything that lived on that host.

Fix it without waiting for upstream

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

These demos are real Safeguard sessions on other tasks; none of them shows PHP2Shell. Each intro explains how the same flow applies to an agency working through client sites.

The first demo shows the CLI fixing a lodash CVE, asking before each command and pushing nothing. For PHP2Shell, you would open the same session in each client repo that builds a PHP image and ask the assistant to move the Dockerfile's base tag to a fixed one such as php:8.3.36-fpm-bookworm, then rebuild and run tests. It asks before each command, so nothing changes in a client repo without your say.

Click through it at your own pace, or open it full screen.

The second demo is the desktop app: the CLI session shows in the conversation list, you ask for work on your computer, pick the folder, and approve or deny each command and file edit until the upgrade is done and tests pass. For an agency, the folder would be one client's project, repeated per client, with each approval on record.

Click through it at your own pace, or open it full screen.

The third demo is a real Android session: work goes to a computer running the CLI, and each command is approved on the phone with Allow once, Allow for turn or Deny. On a night like 21 October, the on-call engineer could approve a client image rebuild from a phone without reaching a laptop.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• PHP news archive 2026: advance notice and 21 Oct security releases (php.net)
• GHSA-6wmf-4rv5-p3rp: RCE via stale global state, CVE-2026-109619 (php-src on GitHub)
• PHP manual: core php.ini directives, expose_php
• UK NCSC: Critical security issue affecting PHP
• CERT-EU Security Advisory 2026-018: Critical vulnerabilities in PHP
• CISA and partners, AA22-131A: Protecting against cyber threats to managed service providers and their customers
• Google Cloud: Responding to core PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619
• Cloudflare: protections against the php2shell vulnerability
• Huntress: php2shell, leaked critical PHP vulnerabilities
• Sansec: PHP2Shell, critical PHP RCE
• Reclaim Hosting: PHP2Shell vulnerability
• Mattias Geniar: PHP CVE-2026-109618 and CVE-2026-109619 early mitigation steps
• cPanel API docs: return PHP version of all virtual hosts
• catalyst2 knowledge base: batch updating PHP versions using WHM API 1
• Plesk CLI reference: php_handler
• WordPress documentation: Site Health screen

Last reviewed: 21 October 2026. This is a developing story; check the linked advisories for the latest status.