PHP2Shell: what PHP and WordPress owners should do right now

I've been writing and hosting PHP for over twenty years — from PHP 4 shared hosting through to today's containerised WordPress and Laravel stacks. I've seen plenty of "patch now" advisories, and most of them turn out to be narrow. This one isn't. When CISA, CERT-EU and ENISA all publish on the same day and the PHP Foundation says "it is imperative that you update now", it's worth stopping what you're doing.

What actually happened

On 21 October 2026 the PHP project shipped emergency releases fixing two related flaws. Both come from the same root problem: when a request ends abnormally, PHP can leave its memory in a corrupted state that a later step — or a later request — trusts.

• CVE-2026-109618 — out-of-memory corruption (CVSS 9.2). If a request hits memory_limit at exactly the wrong moment — for example while PHP is parsing a multipart file upload — cleanup can treat half-built internal data as valid. On Apache with mod_php this can be triggered before any of your application code runs, and full RCE was demonstrated with default settings.
• CVE-2026-109619 — stale global state. A fatal error at the wrong point can leave internal pointers aimed at memory from a previous request. The next request on that worker uses freed memory: a classic use-after-free, with memory disclosure and RCE demonstrated against a real-world application.

Proof-of-concept code is already circulating. Assume scanning has started.

Am I affected?

If PHP answers HTTP requests on the server, yes — unless it's already on a fixed version. Check:

php -v                 # CLI version (may differ from web!)
php-fpm8.3 -v          # FPM binary on Debian/Ubuntu
# Best check: what the web server actually runs
echo '<?php echo PHP_VERSION;' > /var/www/html/v.php  # then visit it, then DELETE it

Places PHP hides that people forget:

• Multiple PHP versions side by side in cPanel (EasyApache/MultiPHP), Plesk or CloudPanel — every one needs patching.
• Docker images built months ago from php:8.x-apache or php:8.x-fpm — rebuild, don't just restart.
• Appliances and third-party products that bundle PHP (control panels, monitoring tools, NAS boxes). The NCSC-NL php2shell list tracks these.
• That "temporary" staging server from 2019 nobody remembers.

How to patch

Debian / Ubuntu (Ondřej Surý PPA or packages.sury.org):

sudo apt update
sudo apt install --only-upgrade 'php8.*'
sudo systemctl restart php8.3-fpm apache2   # adjust to your versions

RHEL / Alma / Rocky (Remi):

sudo dnf upgrade 'php*'
sudo systemctl restart php-fpm httpd

Docker: bump the base image tag, rebuild with --pull --no-cache, redeploy.

Shared or managed hosting: you usually can't patch this yourself. Check your host's status page or open a ticket and ask for the exact PHP build running your account. Don't accept "we're looking into it" for long.

The step people skip: restart. FPM pools and Apache children keep the old binary in memory until they're restarted. Re-check PHP_VERSION from the web afterwards.

WordPress owners: read this bit

• Updating WordPress, themes or plugins does not fix this. It's a bug in PHP itself, beneath WordPress. The fix is at the server.
• Go to Tools → Site Health → Info → Server to see which PHP version your site runs. If it's not one of the fixed versions, chase your host.
• WordPress sites are juicy targets because there are millions of them and upload handling (media library, forms plugins) is everywhere — exactly the path CVE-2026-109618 abuses.
• Sites "stuck" on PHP 7.4 because an old theme or plugin breaks on 8.x are now a real liability. This is the push to finally fix that compatibility debt.

If you genuinely can't patch today

• Move off mod_php. It's the highest-risk setup. Switching Apache to PHP-FPM via proxy_fcgi reduces exposure (FPM is still affected — this buys time, not safety).
• Put a WAF in front (Cloudflare, Sucuri, ModSecurity with updated rules). Helpful, not a fix.
• Tighten uploads. Lower post_max_size and upload_max_filesize, block multipart POSTs to endpoints that don't need them.
• Recycle workers often (pm.max_requests low) to shorten the window for stale-state reuse.
• Unsupported PHP (8.1 and older): CISA's advice is blunt — take it offline until patched. Minimal source backports exist for 7.4, 8.0 and 8.1, and some distros/LTS vendors ship them, but this is the moment to plan the upgrade.

What if I'm on an old PHP version with no patch available?

If your host or vendor cannot provide a security patch for your old PHP version, don't assume the site is safe just because it still works. The temporary measures above are not a substitute for patching. Restrict access or take the affected system offline while you arrange a supported upgrade or replacement.

Sometimes an upgrade is held back by much more than PHP: an abandoned framework, unsupported WordPress plugins, or years of custom code that nobody wants to touch. In that situation, spending more money keeping the old system alive may not be the best answer. A rebuild can be an opportunity to replace the risk and improve how the business works.

feeed's rebuild-from-scratch service starts by capturing what your existing system did, what your business needs now, and what it will need in the future. We use our AI-powered requirements discovery and management solution to turn that understanding into a clear scope, rather than simply copying every legacy feature and limitation.

We then build a cost-effective replacement in weeks, not months, with priorities and scope agreed around your business. Our test and verification platform helps check the replacement against those requirements. We also plan the data migration and handover, so moving away from old PHP is a managed change, not another emergency.

Stuck on legacy PHP? Email russell@feeed.com to discuss a rebuild. We'll start with what your system does and what your business actually needs.

Have I already been hit?

Look for:

• PHP worker processes (www-data, apache, nginx) spawning sh, bash, curl or wget.
• New or recently modified .php files — especially in wp-content/uploads, where PHP should never live:

  find /var/www -name '*.php' -mtime -3 -ls
  find /var/www -path '*uploads*' -name '*.php'

• Unknown WordPress administrator accounts, new cron jobs, unfamiliar SSH keys.
• Unexpected outbound connections or spikes in PHP worker crashes (segfaults in the error log) — crashes are a side effect of exploitation attempts.

If you find anything, patching alone isn't enough: rotate credentials and salts, restore from a known-good backup, and investigate properly.

Lessons from twenty years of PHP hosting

• Know what you run. A simple inventory of every server, PHP version and site turns a panic day into an hour's work.
• Stay on supported versions. The PHP project only patches supported branches. "It still works" isn't a security strategy.
• Automate security updates (unattended-upgrades, dnf-automatic, scheduled image rebuilds) and automate the restart.
• Prefer PHP-FPM over mod_php and run each site under its own user, so one compromise doesn't become all of them.
• Never allow PHP execution in upload directories. One web server rule has saved more WordPress sites than any plugin.

Need a hand?

feeed can audit your PHP and WordPress estate, apply and verify the patches, and help migrate legacy sites off unsupported PHP versions. Email russell@feeed.com — we'll get back to you today.

Sources

• The PHP Foundation — Today's PHP Security Release
• php.net security advisory
• CISA — Critical Vulnerabilities in PHP Require Immediate Patching
• CERT-EU Security Advisory 2026-018
• ENISA — Joint statement on critical PHP vulnerabilities
• BleepingComputer — PHP ships emergency patches for critical PHP2Shell flaws