PHP2Shell: An Urgent Response Checklist for MSPs

By Alaukik K. Singh, founder of MSPHustle Updated October 23, 2026 16 min read

I am a marketer, not a security researcher, so nothing on this page is new technical research. It gathers what PHP, Qualys, Huntress, watchTowr, JFrog, Akamai and national cyber agencies have published, points out where they disagree, and adds the two parts I can speak to: telling your clients, and protecting your own website. Every claim carries its source at the bottom. Where something is my judgment, it says so.

What happened

Details of two PHP vulnerabilities leaked online on October 20, before the coordinated disclosure PHP had planned. Huntress reports that watchTowr confirmed the leaked flaws were real, and that PHP had already given advance notice that a fix would ship on October 21 at 14:00 UTC. PHP also said it reserved the right to release sooner if details became public. Fixes then shipped for four PHP branches.

The two flaws in plain English

The vector PHP published marks attack complexity as high. Qualys ties that to memory layout, the PHP build and how requests land on workers, which is why not every attempt will succeed. That is a reason attacks may be unreliable, not a reason to wait.

The researchers do not describe the bugs identically. JFrog treats the two CVEs as the same underlying defect seen from two angles, and reconstructs one exploit chain through PHP’s session upload-progress feature. That reconstruction is JFrog’s, not PHP’s, so use it as background rather than as the official account.

Who is exposed

• Any PHP serving web requests. PHP’s guidance, as relayed by Qualys and Huntress, lists PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed.
• Apache mod_php first. BleepingComputer quotes PHP rating the risk highest for mod_php, where an unauthenticated request can trigger the attack before any application code runs.
• Command-line use is not discussed. The sources I read describe web-serving installations and do not address CLI-only scripts.
• The bug is in PHP, not in your CMS. WordPress, Drupal, Joomla and Magento sites run on PHP, so they are exposed through the server’s PHP. CybelAngel notes that updating the CMS or its plugins does not apply the fix.
• PHP you did not install. Huntress warns that PHP is also bundled in vendor appliances, control panels and Windows software that do not advertise it.

Internet-wide counts of exposed PHP hosts are in the millions, and the figures depend on the method. BleepingComputer cites a VirusTotal estimate above 5.1 million hosts, while CybelAngel cites Shodan-based counts of about 2.24 million. Both count hosts, not organizations, so use them for scale only.

Is it being exploited?

The sources disagree on detail. Here is what each one says, and when.

The sources I read describe attack attempts and demonstrations. None documents a named victim. My reading, which is an opinion and not a finding: an unauthenticated, remotely triggerable flaw with leaked details and public reports of attack traffic is worth treating as actively targeted until you have patched, and the cost of that assumption is a few hours of patching you were going to do anyway.

Check a PHP version

Enter the PHP version a server reports and how PHP is served. The checker compares it with the fixed releases published by PHP. It runs in your browser and sends nothing anywhere.

What to patch first

This order is my own, built from the advice in the Huntress and watchTowr write-ups. It is not an official ranking.

Step 1: Find every PHP install

Huntress recommends starting with an inventory of every PHP installation, including PHP bundled in vendor appliances, Windows software, control panels and CMS deployments. The check list below turns that into tasks.

• List every internet-facing web server you manage, including client servers, staging servers and anything a former project left running.
• Record how each one serves PHP: mod_php, PHP-FPM, LiteSpeed, FrankenPHP or php-cgi.
• Record the PHP version of the web process, not only the command line. The command-line php -v reports the CLI binary, which can differ from what the web server loads.
• Add vendor software that bundles PHP: control panels, ticketing or help desk tools, backup consoles, monitoring portals and line-of-business apps.
• Add client-hosted sites that you do not manage but that clients may expect you to answer for.
• Open a ticket per system so you can show a client exactly what was checked, and when.

These commands are common starting points. Names and paths vary by distribution, so adapt them.

apachectl -M | grep -i php      # Apache: is mod_php loaded?
php-fpm -v                      # PHP-FPM (the binary may be named php-fpm8.3 -v)
php -v                          # CLI only, which can differ from the web version
rpm -q --changelog php-fpm | grep -i CVE-2026-10961    # RPM: look for the fix by CVE
apt changelog php8.3-fpm | grep -i CVE-2026-10961      # Debian or Ubuntu: same idea

On Windows with IIS, php-cgi.exe -v reports the version of the binary the site calls. Distribution builds may keep an older upstream version number while carrying the fix, which Qualys flags, so the changelog search matters as much as the version.

Step 2: Patch and restart

1. Update to the fixed release for the branch, or to your distribution’s patched package. The fixed releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Huntress says Linux distributions and LTS vendors received patches early, so check their packages first.
2. Restart every PHP worker, not only the service you updated. watchTowr’s guidance is to restart all PHP workers after updating, because a running process keeps the old code in memory.
3. Confirm the running version, using the checker above or the commands in step 1.
4. Test the things clients notice: logins, forms, bookings and payments.
5. Close the ticket with evidence: version before, version after, time of restart.

Control panels and hosts. If a panel or host controls PHP for you, you may be waiting on them. In a Plesk community forum thread I read, a Plesk community manager said shortly before the release that fixed versions would be added to Plesk PHP packages but gave no precise ETA, and users in the same thread were asking whether older branches would be backported. That thread is a snapshot, not a current status. Ask your own panel and host vendors for a written answer, and record it.

If you cannot patch yet

PHP says updating is the only complete fix, and watchTowr repeats that PHP states no configuration change fully mitigates these flaws. The measures below, as relayed by Qualys, JFrog and BleepingComputer, only reduce known attack paths, and each has a cost. Use them as a bridge, restart the PHP workers after changing settings, and keep the patch ticket open.

Step 3: Look for signs of misuse

Patching closes the door. It does not tell you whether anyone walked through it first. Huntress says the most likely sign of exploitation is suspicious child processes spawned by PHP. It also said Sigma and YARA rules and indicators of compromise were still to be published when it wrote.

• Process watch: PHP workers (php-fpm, php-cgi, httpd, apache2 and php-cgi.exe on Windows) launching shells such as sh, bash, cmd.exe or powershell.exe, interpreters such as python or perl, or download and network tools such as curl, wget, nc or certutil.exe.
• Command lines: reverse-shell patterns such as /dev/tcp/, fsockopen and mkfifo, and reconnaissance commands such as whoami, id, uname -a or ipconfig.
• The file system: new or changed files in web roots, new cron jobs or scheduled tasks, and new accounts.
• If you suspect compromise: isolate the server, preserve web and PHP logs, and check for webshells before you clean anything up.

Without EDR on a Linux server, Huntress suggests Florian Roth’s process-watching tool in observe mode.

Unsupported PHP versions

PHP 8.1 and earlier no longer receive official updates. PHP provided minimal source backports for 7.4, 8.0 and 8.1, which CybelAngel describes as meant for people who build PHP themselves, not for typical hosting accounts. watchTowr confirmed that older unsupported branches, including PHP 5, are affected, and the Singapore CSA says the flaws affect all versions of PHP.

That leaves four options. Pick one per system and put the decision in the ticket.

1. A vendor or LTS package that lists both CVE IDs in its advisory.
2. An upgrade to a supported branch. Huntress recommends the latest 8.5.x where testing allows. CybelAngel notes that PHP 8.2 is in security-only support until December 31, 2026, so it is a short runway.
3. Isolation: take the system offline, or put it behind a VPN or WAF. Huntress gives this as the answer for end-of-life PHP that cannot be upgraded right away.
4. Third-party patches: Huntress says it cannot evaluate them, so treat them as a risk you are accepting, not a fix.

Telling your clients

This is the part of the response where marketing and operations meet. A calm, specific note often does more for client trust than silence, though that is my opinion and not a measured result. Three rules keep it honest.

Here is a starting point. Replace the brackets, delete anything that is not true for that client, and send the follow-up you promise.

If the note turns into a sales pitch, CAN-SPAM’s rules for commercial email apply. The FTC’s compliance guide, linked below, covers what they require.

Your own website

Your MSP’s marketing site probably runs on PHP too, especially if it is built on WordPress, and it may sit on a shared host you do not control. A compromised MSP site is awkward at any time and worse in the week you are writing to clients about this. For a WordPress site, work through this short list.

• Find out who patches the PHP: you, your host or a managed WordPress provider.
• Ask the host in writing to confirm the patched PHP release or distribution package revision, and that the workers were restarted.
• Do not treat a WordPress or plugin update as the fix. It does not touch the PHP runtime.
• Test after the update: contact forms, the audit request form, logins and any booking tool.
• Review the logs for unusual requests or file changes, and keep a recent backup.
• Remove any test page that prints PHP configuration if one is still public.

If the check turns up a site that is slow, dated or hard to update, that is a design and hosting decision for a calmer week. The MSP website design page covers how MSPHustle approaches it.

Frequently asked questions

Alaukik K. Singh

Founder of MSPHustle, an AI-powered MSP marketing agency. 12+ years in digital marketing, including six years marketing inside the MSP industry: websites, SEO, paid search, events and webinars. Certified in Google Ads, Google Analytics, Meta Blueprint and HubSpot. MBA in IT and Marketing. MSPHustle is a marketing agency, not a security vendor. More about me or connect on LinkedIn.

Sources

• PHP project, security announcements, October 2026. This is the primary advisory, which the Singapore CSA and Akamai reference. The facts above are as relayed by the sources below.
• Qualys, “PHP Announces Critical Security Release for Two Vulnerabilities” (October 20, 2026)
• Huntress, “Rapid Response: php2shell, Leaked Critical PHP Vulnerabilities”
• watchTowr, “PHP2Shell FAQ: CVE-2026-109618 and CVE-2026-109619 Fixes” (updated October 22, 2026)
• JFrog Security Research, “PHP2Shell: All You Need to Know About CVE-2026-109618 and CVE-2026-109619”
• BleepingComputer, “PHP ships emergency patches for critical PHP2Shell flaws”
• Cyber Security Agency of Singapore, “Critical Vulnerabilities in PHP” (AL-2026-151)
• Akamai, “Critical Remote Code Execution Vulnerabilities in PHP Core” (October 21, 2026)
• CybelAngel, “2.24M Internet-Facing PHP Hosts, 59% on Versions With No Fix Coming”
• Plesk Community, “ETA for critical PHP security updates (CVE-2026-109618 / CVE-2026-109619)?” (forum thread)
• Federal Trade Commission, “CAN-SPAM Act: A Compliance Guide for Business”