Urgent PHP Security Update: PHP2Shell Fix Guide

If your website runs on PHP — and that includes every WordPress site — this one can't wait until next week.

On 21 October 2026 the PHP security team released fixes for two critical bugs, now nicknamed PHP2Shell. Both are rated 9.2 out of 10. An attacker can run their own code on your server without logging in, and on some setups it happens before a single line of your website's code runs.

The fix is already out. Here's who is at risk, what the bugs are in simple words, and exactly what to do.

The short version

What: two critical PHP bugs — CVE-2026-109618 and CVE-2026-109619. Both CVSS 9.2. Remote code execution, no login needed.
Who: almost every PHP installation that serves web pages.
Fix: update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 — or your Linux distribution's patched package.
When: today. Exploit attempts were seen before the official release.

Timeline

17 October — Amazon's honeypots recorded an exploit attempt, four days before the public release.
20 October — the PHP team announced a critical release was coming. The CVE IDs leaked online the same afternoon (a wrong "10.0" score circulated with them — the official score is 9.2).
21 October, 14:00 UTC — fixed versions and full details published on php.net.

Who is at risk

Almost everyone. Every PHP install that serves web requests is affected:

PHP-FPM (most modern hosting, Nginx setups, Laravel Forge servers)
Apache with mod_php
PHP-CGI
FrankenPHP
LiteSpeed (common on shared hosting)

The risk is highest for Apache with mod_php. There, an attacker's request can trigger the attack before any of your application code runs — so nothing in your own code, plugin or firewall-inside-WordPress can protect you.

The two bugs, in plain English

Bug 1: the half-written order (out-of-memory corruption)

Think of a waiter writing down a customer's order. Halfway through, the waiter is stopped. The order is only half-written. Later, the clean-up step reads that half-written order as if it were complete.

In PHP, this happens when a request runs out of memory at exactly the wrong moment. The clean-up code then trusts broken data — and an attacker can shape that data to take control. This is CVE-2026-109618.

Bug 2: the hotel room that wasn't cleaned (stale global state)

Think of a hotel room. One guest checks out, but the room isn't cleaned yet. The next guest walks in and uses what the last guest left behind.

In PHP, one worker process handles many requests, one after another. After a fatal error, some internal data from an old request can survive after its memory is freed. The next request on the same worker can use that old data before PHP resets it. This is CVE-2026-109619.

What to do: update PHP today

The safe versions are:

PHP 8.5.12
PHP 8.4.27
PHP 8.3.36
PHP 8.2.35

On a Linux server (VPS, dedicated, cloud): Linux distributions got the patches in advance, so check for updated packages first (apt update && apt upgrade on Ubuntu/Debian, dnf upgrade on RHEL/Alma/Rocky). Their version numbers can look different — distributions often add the fix to an older version and append their own build number. Compare your package with your distribution's security notice, not just the PHP version list above.

Using the Remi repository? The PHP team says the volunteer-run rpms.remirepo.net didn't have updates on release day. Switch to your distribution's packages or build from source.

On PHP 8.1 or older: the PHP project no longer ships updates for these. The security team published small source patches for 7.4, 8.0 and 8.1, and some distributions and long-term-support vendors backport fixes — but the real plan is to move to a supported version.

On shared or managed hosting: your host patches PHP for you, but check that it actually happened. In your hosting panel (hPanel, cPanel, Plesk), look at the PHP version your site uses, and ask support to confirm the patched build. If you're still on PHP 8.1 or older, switch to 8.3 or 8.4 — test the site afterwards.

On Laravel Forge or similar: Forge's automatic security updates do not patch PHP. Update it yourself.

Check which PHP you actually run

On the command line:

php -v

But be careful: the command line can use a different PHP than your web server. Check the version your website really runs:

the PHP-FPM service: php-fpm8.3 -v (or systemctl status php8.3-fpm to see which one is running)
or a temporary info page — create info.php containing <?php phpinfo();, open it once in the browser, then delete it straight away
WordPress: Tools → Site Health → Info → Server shows the PHP version

After updating, restart PHP-FPM / Apache so the old workers are replaced.

If you can't update today: settings that reduce the risk

The PHP team is very clear: only an update is a complete fix. These settings block the known attack paths but do not make your server safe. Use them only as a stop-gap.

Put them in php.ini, the FPM pool or the Apache configuration — somewhere that applies before the request is read. Don't rely on ini_set() in your code or .user.ini files.

; php.ini
memory_limit = -1                    ; removes the controllable out-of-memory trigger (bug 1)
post_max_size = 8M                   ; 32M if your site needs file uploads
upload_max_filesize = 8M             ; keep below post_max_size
session.upload_progress.enabled = 0  ; blocks the confirmed paths for bug 2
fatal_error_backtraces = 0           ; PHP 8.5 only

; PHP-FPM pool — stops applications putting a memory limit back
php_admin_value[memory_limit] = -1

Then restart every PHP worker. Because memory_limit = -1 removes PHP's own memory cap, keep a container or cgroup memory limit in place so one runaway request can't take down the whole server.

If you use Cloudflare, it has added WAF rules for the known exploit patterns (free plan included). That's a useful extra layer — not a fix.

Running PHP in Docker or containers?

Updating the host is not enough — the PHP is inside your image.

Pull the newest base image (for example php:8.4-fpm).
Check the PHP version inside it: docker run --rm php:8.4-fpm php -v.
Rebuild your images.
Redeploy every container.
Search your registries for old images still running somewhere — staging, cron workers, queue workers.

Checklist

Find every server and site that runs PHP (don't forget staging and old client sites)
Check the PHP version the web server uses, not just php -v
Update to 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 or your distribution's patched package
Restart PHP-FPM / Apache
Rebuild and redeploy containers
Plan an upgrade for anything on PHP 8.1 or older
Can't update yet? Apply the settings above and restart workers — then update as soon as you can

Official sources

Need help patching?

If you're not sure which PHP your sites run, or you have old client sites on PHP 8.1 or older, we can check and update them for you — see our website maintenance and development services or send us a message. Do it today.

Urgent PHP security update (October 2026) — two critical bugs, who is at risk and exactly what to do