Security note

PHP2Shell: the fix, and what to do if your site runs WordPress

Published October 21, 2026

Short version: two critical bugs in PHP itself were disclosed on October 21, 2026. The fix is a PHP update on the server, not a WordPress update. If your site runs PHP 8.2 or newer, get it to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. If it runs anything older, ask your host for their patched build today, or take the site offline until they have one.

What PHP2Shell is

PHP2Shell is the nickname for CVE-2026-109618 and CVE-2026-109619, two bugs in the PHP engine. Both let an attacker send a crafted web request that interrupts PHP mid-request, and then run their own code on the server or read its memory. No login needed. The PHP project rates both 9.2 out of 10, and the affected code goes back to PHP 5.4 from 2012, so nearly every PHP version released since is affected by at least one of them.

The part that matters for a business owner: the bug triggers before your website's own code runs. A clean theme, a well-maintained plugin list, and the latest WordPress, Drupal, Joomla, Magento or Laravel release don't change it. Only the PHP runtime on the server does.

The researchers who found it (Calif, OpenAI and Wiz) showed working attacks against current WordPress, Drupal and Joomla installs. Attack attempts were reported before the patch shipped. CISA said it hadn't observed exploitation as of its October 21 alert and still told everyone to patch immediately.

The official fix

Update PHP to one of these releases, then restart PHP (Apache, PHP-FPM, or whatever runs it):

Branch	Patched release
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35

PHP 7.4, 8.0 and 8.1are past end of life, so the PHP project published source patches only, no installers. Ubuntu (older releases through Ubuntu Pro) and AlmaLinux shipped fixed packages for those branches on October 21, and the version number you see often doesn't change. Check the package version or your vendor's advisory, not just the number.
PHP 5.x to 7.3 get nothing from the PHP project. Ubuntu Pro and AlmaLinux 8 shipped fixes for some of those branches; anything else still on them needs to move.
Docker and container images:rebuild on a patched base image and redeploy. A patched laptop or staging box doesn't help if production still runs the old image.

If someone else runs your hosting

Most small-business sites are on shared or managed hosting, where the PHP version is the host's to change. Two things to do today:

Look for a PHP version setting in your hosting panel (cPanel and Plesk both have one) and switch to the newest option. If the newest option is older than the table above, go to step 2.
Ask support, in writing: “Which PHP build is my site on, and is it patched for CVE-2026-109618 and CVE-2026-109619?” Keep the answer. A good host will name the package version.

If you can't patch today

The PHP project is blunt: there are no complete mitigations, updating is the only safe choice. These reduce exposure while you wait. The settings are from PHP's own advisory, the firewall advice from CISA:

Put a web application firewall in front of the site. Cloudflare turned rules on by default for free and paid plans, and Vercel did the same for sites that route through it. A firewall only covers traffic that goes through it.
Have the host set session.upload_progress.enabled=0 and memory_limit=-1 at the server level (php.ini or the FPM pool, not a per-site override) and restart every PHP worker. With the PHP limit off, cap memory with a container or cgroup limit instead, never RLIMIT_AS or RLIMIT_DATA, which PHP says can trigger the bug. On PHP 8.5, also fatal_error_backtraces=0.
Keep request sizes small: a low post_max_size, and limits on upload size at the web server.
CISA's advice for anyone who can't patch, or is stuck on PHP 8.1 or older: take the site offline until you can.

Signs something already happened

Memory-limit errors in the PHP log right after unusual or oversized multipart requests, especially ones logged at Unknown on line 0: PHP died before any script ran, which Datadog calls out as the tell for this bug.
Oversized or malformed PHPSESSID cookies in responses, or worker crashes and bursts of HTTP 500s that line up with those requests.
A PHP process starting a shell or downloading tools. That one is a call to your host, today.

None of these alone proves an attack, and a refined exploit can leave no crash at all, so patching still comes first.

Where my own work stands

Checked October 21, 2026: nothing I run uses PHP. This site and the client sites I built and host are static HTML or Next.js on Vercel, Netlify and Cloudflare, and there is no PHP in my toolchain. Nothing to patch on my side.

Not sure what your site runs?

Send me the URL and I'll tell you what it runs and whether it's on the list, free, no pitch. Use the start form or email bsichel@blakelike.com.

Questions people are asking

What is PHP2Shell?

The name for two bugs in the PHP engine, CVE-2026-109618 and CVE-2026-109619, disclosed on October 21, 2026. A crafted web request can interrupt PHP mid-request in a way that lets an attacker run code on the server or read its memory, with no login. The PHP project rates both 9.2 out of 10.

What PHP version fixes PHP2Shell?

PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. PHP 7.4, 8.0 and 8.1 only got source patches from the PHP team, but Linux distributions such as Ubuntu and AlmaLinux ship fixed packages for those branches, often without changing the version number you see.

Does updating WordPress fix PHP2Shell?

No. The bug is in PHP itself and triggers before any WordPress code runs. Updating WordPress, a theme or a plugin doesn't touch it. The PHP runtime on the server has to be updated, which on shared or managed hosting is the host's job.

How do I know if my site is affected?

If it runs PHP below the versions above, it's affected. WordPress, WooCommerce, Drupal, Joomla, Magento and Laravel sites all run PHP. In cPanel or Plesk look for a PHP version setting, or ask your host which PHP build your site is on. Not sure what your site runs? Send me the URL and I'll tell you.

What if I can't update today?

The PHP project says nothing short of updating makes a server safe. Until then: put a web application firewall in front of the site (Cloudflare's free plan has rules on by default), have the host set session.upload_progress.enabled=0 and memory_limit=-1 at the server level and restart PHP, and, per CISA, take the site offline if you can't patch or it's still on PHP 8.1 or older.