PHP2Shell: A Practical Checklist for Agencies Managing WordPress and PrestaShop Sites

October 27, 2026

· By Tarek Smiri

PHP2Shell: A Practical Checklist for Agencies Managing WordPress and PrestaShop Sites

Short answer

PHP2Shell is the name given to two critical vulnerabilities in PHP itself, CVE-2026-109618 and CVE-2026-109619, both rated CVSS 9.2. They were fixed on 21 October 2026 in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 (CrowdSec). The fix is a PHP update on the server, followed by a restart of every PHP worker. Updating WordPress, PrestaShop, a theme or a module does not fix it (PrestaShop). For an agency, the work is simple to describe: for every client site, know which PHP version actually serves the site, who applies the patch, and get written confirmation that it's done. A final section covers how to manage PHP versions across client sites over the long term, so the next PHP advisory becomes a routine check.

What PHP2Shell is, in plain terms

Both flaws are memory-handling bugs in the PHP engine. With specially crafted HTTP requests, an attacker could crash PHP, expose sensitive data or, in the worst case, run code on the server without logging in (PrestaShop help center). According to Sansec, the bugs are present in every unpatched PHP version since 5.4.

Three points matter for agencies:

It concerns the server, not the CMS. CISA lists all PHP installations serving web requests as affected: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, with the highest risk on mod_php.
Plugins and modules can't block it. The attack can happen before any CMS code runs, so a WordPress security plugin or a PrestaShop module is not a protection here (PrestaShop).
Every version of the CMS is concerned. PrestaShop states that every version from 1.6 to 9 is concerned, since they all run on PHP. The same logic applies to WordPress.

Where things stand on 27 October 2026

The picture is serious but not alarming, and it's worth reading it accurately before talking to clients:

CISA added both CVEs to its Known Exploited Vulnerabilities catalog on 26 October 2026.
Sansec tested the code circulating online and wrote that "the public exploits do not work against a default PHP installation."
SecurityWeek reported that a researcher recorded 35 shells across three honeypots running PHP 8.4.26 under Apache mod_php with a single worker. The researcher himself cautioned that this "is not a measurement of exploit reliability" on other configurations.
Between 21 and 25 October, the CrowdSec network recorded 10,073 blocked attempts from 1,187 IP addresses, with no publicly confirmed compromise through PHP2Shell as far as CrowdSec knows.
Sophos corrected an earlier report of a successful exploitation, noted that building an exploit is not straightforward, and still recommends patching urgently.

In short: no reason to panic, and no reason to wait. The patch exists, and the only open question for each client site is whether it has been applied.

The agency checklist, site by site

1. Inventory every site and who manages its server

List each client site with its CMS, its host and who manages PHP: the host (shared or managed hosting), your team, or the client's IT. CISA recommends starting with an inventory and patching internet-facing systems first.

2. Read the PHP version the website really uses

In PrestaShop, the version is under Advanced Parameters > Information. In WordPress, it's in Tools > Site Health > Info > Server. Command-line PHP and web-server PHP can differ, so the value that counts is the one the website reports (PrestaShop). Compare it with 8.5.12, 8.4.27, 8.3.36 or 8.2.35. A lower number is not automatically vulnerable: Linux distributions often backport fixes without changing the version number, which is exactly why the next step matters.

3. Ask the host for written confirmation

For hosted sites, ask one precise question: has the fix for CVE-2026-109618 and CVE-2026-109619 been applied to the PHP version running the site, and when? Ask also that all PHP processes have been restarted since. PrestaShop suggests asking for this confirmation in writing (source). Keep the answer in the client file.

4. If your team manages the server: update, restart, verify

Install the updated PHP packages from the distribution or the official release.
Restart every PHP process: PHP-FPM pools, Apache, LiteSpeed, FrankenPHP workers. An update that is installed but not loaded does not protect the site (PrestaShop, CrowdSec).
For Docker deployments, rebuild images on the updated base image and redeploy.
Test the critical paths afterwards: admin login, contact form, add to cart, a test order.

5. Handle PHP 8.1 and older as a separate case

PHP 8.1 and older get no regular official update. The PHP project published limited source fixes for 7.4 to 8.1, and some hosts or distributions ship their own patched packages (Search Engine Journal). This is common in e-commerce: PrestaShop 8.0 to 8.2 supports PHP up to 8.1 only (PrestaShop). CISA advises taking systems on PHP 8.1 or older offline until they are patched. Note also that security support for PHP 8.2 ends on 31 December 2026 (php.net), so sites on 8.2 need a version upgrade on the roadmap anyway.

6. If a site must go offline, protect its search visibility

Google's guidance, relayed by Search Engine Journal, is to serve a 503 status code during the downtime, not a 404 or an error page returning 200. Practical details:

The 503 must come from something that keeps running while PHP is down, such as a CDN rule or a temporary server.
Keep robots.txt responding normally: a 503 on robots.txt blocks all crawling.
A Retry-After header can tell crawlers when to come back.
Don't keep a 503 for more than one to two days: URLs that return it for several days may be dropped from Google's index.

7. Reduce exposure while the patch is scheduled

A web application firewall filters requests before they reach PHP and is a useful extra layer, but signature-based rules can be bypassed and do not replace the update (PrestaShop). The PHP advisory also lists interim configuration measures; they should be tested on staging first and applied by whoever manages the server.

8. Watch for signs of compromise

CISA recommends watching for PHP worker processes launching shells (source). At site level, PrestaShop lists simple signals: unknown or recently modified .php files, admin accounts nobody created, unexpected redirects, altered content or a modified payment page (source). If in doubt, contact the host immediately.

While you're in the WordPress back office: Rank Math PRO

An unrelated incident is worth checking during the same pass. Rank Math reports that copies of Rank Math PRO 3.0.123 downloaded between 15 October 2026 at 20:02 UTC and 16 October 2026 at 07:12 UTC contained malware. The clean version is 3.0.124. If the affected version was installed and activated during that window, Rank Math says to treat the site as compromised and follow its recovery steps; the free version on WordPress.org is not affected (Rank Math).

How to manage PHP versions across client sites

PHP2Shell will leave the news, but the question behind it comes back every year: which PHP version runs each client site, and how long will it keep receiving security fixes? A short routine answers it before the next advisory does.

Keep a living inventory. One line per site: CMS and version, host, the PHP version the site itself reports, who manages the server and the date of the last check. Update it at every maintenance pass.
Follow the official PHP calendar. According to php.net, each PHP branch gets two years of active support, then two more years of critical security fixes only, before reaching end of life. On the current schedule, security support ends on 31 December 2026 for PHP 8.2, 31 December 2027 for 8.3, 31 December 2028 for 8.4 and 31 December 2029 for 8.5. Plan upgrades months ahead.
Check compatibility before choosing a target version. The WordPress core team publishes a compatibility table for each WordPress release: WordPress 7.0 and 7.1 support PHP 7.4 to 8.5. The PrestaShop developer documentation lists PHP 8.1 to 8.4 for PrestaShop 9.0, and 8.1 to 8.5 for 9.1. The core is not enough: PrestaShop advises checking theme and module compatibility, testing in pre-production and backing up the site and database first (PrestaShop). The same applies to WordPress plugins and themes.
Test on staging, then switch. Change the PHP version on a copy of the site, test the critical paths (login, forms, cart, checkout), read the error logs, and keep a rollback ready.
Get written answers from hosts. Ask managed hosts which PHP versions they offer, when older ones will be withdrawn and how security patches are announced. File the replies.
Monitor between visits. Uptime monitoring and a regular look at the PHP error logs catch most problems that follow an update.
Name an owner. Someone must watch the calendar, schedule upgrades and inform the client: a named person per portfolio, or a maintenance partner with a written scope.

Our fixed-price monthly maintenance is built around this routine. Tell us about your sites.

What to tell clients

Keep it factual: a critical flaw was fixed in PHP on 21 October; the fix is a server update; here is the PHP version your site runs, who patched it and when. No dramatisation is needed, and none is accurate today. What clients value is the written trace that their site was checked.

How Genesis Digital Factory fits in

We build and maintain WordPress and PrestaShop sites in white label for agencies, under your brand. Our monthly maintenance is billed at a fixed monthly price: updates, checks and follow-up are planned, rather than handled in a rush each time a vulnerability makes the news. Since 2005, we have delivered more than 85,000 projects, 99% of them on time. See our white-label WordPress development and white-label PrestaShop development pages, or tell us about your sites through the contact page.

FAQ

Does updating WordPress or PrestaShop fix PHP2Shell?

No. The flaws are in PHP, so the fix is a PHP update on the server, followed by a restart of the PHP workers.

Which PHP versions are fixed?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, or a patched package from the Linux distribution or host.

Have sites been hacked at scale?

Not according to the sources available on 27 October 2026: CrowdSec reports attempts but no publicly confirmed compromise, and Sansec says public exploits do not work against a default PHP installation. Patching remains urgent.

Our client is on PHP 8.1. What now?

Ask the host whether a patched package is available, apply the interim measures with whoever manages the server, and plan a move to a maintained PHP version. CISA advises taking PHP 8.1 or older systems offline until patched.