PHP2Shell: Why Patching Your Website Isn’t Enough This Time

By El Mostafa Ouchen | MAG212 CYBER | 22 October 2026

If your business runs a PHP website, whether WordPress, Drupal, Joomla, Magento, Laravel or something custom, you need to act this week. Two critical flaws in the PHP engine itself, tracked as CVE-2026-109618 and CVE-2026-109619 and together called “PHP2Shell”, let an attacker run code on your server or read data from its memory without logging in.

The important part: the bug is not in your website. It’s in the PHP runtime underneath it. A fully updated WordPress on an unpatched PHP server is still exposed.

Key facts

• CVEs: CVE-2026-109618 (RCE via OOM corruption) and CVE-2026-109619 (RCE via stale global state)
• Severity: Critical. CVSS v4 9.2 (PHP); NVD v3.1 9.8 for CVE-2026-109618
• Affected: All web-serving PHP: Apache mod_php, PHP-FPM, php-cgi, FrankenPHP, LiteSpeed. Back to PHP 5.4
• Fixed in: 8.5.12, 8.4.27, 8.3.36 and 8.2.35 (released 21 October 2026)
• Status (22 October): Exploit attempts confirmed; no confirmed compromises; not in CISA KEV

What happened

PHP shipped fixed versions on 21 October 2026, a day earlier than planned after details leaked online. Both flaws come from PHP mishandling memory when a request ends abnormally, for example when it runs out of memory. One flaw can turn that into remote code execution. The other lets a later request reuse data that should have been wiped, which can expose passwords, session tokens, API keys and certificates belonging to other users.

Who is affected

Practically every PHP installation that serves web pages, going back to PHP 5.4:

• Apache mod_php: the easiest target, exploitable with default settings
• PHP-FPM, php-cgi, FrankenPHP and LiteSpeed

Estimates of exposed servers range from 1.3 million to over 5 million, depending on who is counting.

Is anyone being attacked?

Attack attempts are confirmed. Security networks recorded probing as early as 17 October, before the public announcement, and scanning spread across the internet within hours of the leak. As of 22 October, no successful break-in had been publicly confirmed.

That is not the same as “no one was hacked.” A successful attack can return a normal page and leave nothing in your website’s logs. Several organizations, including BambooHR and the Dutch government’s DigiD service, briefly took systems offline as a precaution. The UK’s NCSC told organizations to update immediately or take affected systems offline.

What to do now

1. Update PHP and restart it. The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Restart every PHP process afterward; installing the update alone isn’t enough.

2. If you’re on hosting, ask your provider today: “Which PHP version is my site running, and has it been patched for CVE-2026-109618 and CVE-2026-109619?” On shared hosting, managed WordPress or an agency-run server, PHP is usually their responsibility, not yours. Get a written answer.

3. Can’t patch yet? Put your site behind a web application firewall; Cloudflare has enabled protective rules on all plans. Also apply PHP’s interim settings, which block known attack paths: set session.upload_progress.enabled = 0 and fatal_error_backtraces = 0.

4. Assume secrets may have leaked. If your site ran a vulnerable PHP version on the internet after 17 October, change your database passwords, API and payment keys, and admin passwords, and log out all sessions. Do this even if you find no sign of a break-in, because the memory-leak attack leaves almost no trace.

5. Check for old PHP. PHP 7.3 and older will never get a fix. PHP 8.1, 8.0 and 7.4 have only source-code patches unless your Linux vendor provides one. PHP 8.2 reaches end of life on 31 December 2026. If your site runs any of these, plan an upgrade now.

The bigger lesson

Most businesses update their website and plugins and assume they’re covered. PHP2Shell shows the danger sits one layer down. The organizations hit hardest won’t be the ones that patch slowly. They’ll be the ones that can’t say, within minutes, which PHP version each server runs and who is responsible for updating it.

Find out today who owns your PHP runtime. That one answer decides how fast you can respond, this time and next time.

The full technical report, with firewall rules, detection queries and an incident response checklist, is available in the MAG212 CYBER magazine. Information is current to 22 October 2026; check PHP’s official advisories before acting, as patch and exploitation status are changing quickly.