Published 21 October 2026 · Based on advisories and coverage available on release day

The short version

On 21 October 2026 the PHP project shipped emergency updates for two critical bugs in PHP itself. Researchers and vendors are calling the pair “PHP2Shell.” Each scores 9.2 out of 10 (CVSS v4.0), and each can let an attacker run their own code on your server without logging in.

Because the bugs live in the PHP engine, not in any one app, a site is exposed whether it runs WordPress, Drupal, Magento, Joomla, Laravel or hand-written PHP. The fix is to update PHP.

PHP branch	Fixed version
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35

If you remember one thing: patch PHP today, then check that you weren’t already hit.

What happened

On 20 October the PHP security team pre-announced a release for 21 October at 14:00 UTC. Later that day the two CVE numbers started circulating online with a wrong release time and a wrong score (10.0 instead of 9.2), so PHP moved its announcement forward. The PHP Foundation said the coordinated disclosure had held until about two days before the planned release.

One security vendor, Patchstack, reported confirmed exploitation attempts after details leaked, while PHP’s own release text does not report any. Treat that as a reason to move fast, not a reason to wait for certainty.

The bugs were reported by Wiz Research, and watchTowr confirmed they were real before the release. Wiz says every PHP version going back to 5.4 is affected by at least one of the two issues, and that PHP’s patch addresses the root problem, including other variants.

A quick mental model: how PHP handles a visit

When someone requests a page, PHP sets up a temporary workspace for that request, uses it, and then tidies it away. Long-running PHP workers repeat this cycle again and again for different visitors.

Both bugs break that cycle. In each case PHP trusts something in its workspace that it should not.

(This is a simplified analogy for understanding, not a description of how an attack is carried out.)

CVE-2026-109618: “RCE via out-of-memory corruption”

In plain terms: PHP caps how much memory a request may use. If a request hits that cap at exactly the wrong moment, PHP can be interrupted while it is half-way through setting something up. The leftover data is incomplete, but PHP later treats it as if it were fine, which corrupts memory.

Analogy: a cook is stopped mid-recipe, and the next step reads the half-prepared ingredients as if they were finished.

Why it matters: memory corruption in a language runtime is the kind of flaw attackers can often steer into running their own commands on the server. The score reflects that it can be reached over the network with no login.

CVE-2026-109619: “RCE via stale global state”

In plain terms: a fatal error at the wrong point can leave PHP’s internal state pointing at memory that has already been freed. A later request handled by the same worker can then use that stale information before PHP resets it.

Analogy: a hotel room is cleaned and handed to a new guest, but the previous guest’s key card still opens it, and the room’s contents are no longer what the hotel thinks they are.

Why it matters: use of freed memory is another classic route to code execution. It also means one visitor’s request can influence what the next request experiences.

Why this one is a big deal

• No login needed. The attacker only has to reach your web server.
• It’s the engine, not the app. Plugins, themes and frameworks can all be perfectly up to date and still sit on a vulnerable PHP.
• Every common setup is covered. PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed are all affected.
• Very wide reach. PHP powers a large share of the web, and security researcher Kevin Beaumont predicted a flood of incidents.
• “Remote code execution” is the worst-case outcome. It means an attacker can run commands as your web server, typically leading to web shells, stolen data, defaced sites, crypto-miners or a foothold for moving deeper into your network.

Who is affected?

• Anyone running PHP 8.2 to 8.5 below the fixed versions above.
• Anyone running PHP 8.1 or older, which the PHP project no longer patches. The vendors’ guidance is that older versions need a vendor backport or an upgrade.
• Anyone on shared or managed hosting, because it is your host who controls the PHP version.
• Anyone using appliances, control panels or products that bundle PHP. The UK’s NCSC specifically warns about these and advises identifying PHP installations generally, not just outdated ones.

How to fix it

1. Update PHP (the real fix)

Upgrade to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, then restart your PHP process so the new binary is actually running (PHP-FPM, Apache, LiteSpeed or your container).

A few practical notes:

• Linux distributions and LTS vendors received the patches before the public release. Check your vendor’s package updates (for example apt, dnf or your container base image) rather than compiling from source.
• Containers: rebuild and redeploy images. Patching the host does nothing for a container that bundles its own PHP.
• Shared hosting or managed WordPress: contact your host and ask which PHP build you are on and when it was patched.
• Confirm the result with php -v on the command line and a version check through the web server, since the two can differ.

2. If you’re on PHP 8.1 or older

The PHP project will not release a fix. Your options, in order of preference:

1. Upgrade to a supported branch (8.2 or newer; note that 8.2 is itself only receiving security fixes until 31 December 2026, so 8.3 or newer is a better target).
2. Ask your OS or LTS vendor for a backported fix. Some distributions and extended-support vendors provide one.

3. Temporary stopgaps (only if you truly cannot patch yet)

These reduce risk but do not fully close the holes. Updating is the only complete fix.

• For CVE-2026-109619: setting session.upload_progress.enabled = 0 in your PHP or server configuration and restarting PHP blocks one known attack path.
• For CVE-2026-109618: PHP’s guidance describes a partial mitigation that involves enforcing memory limits at the server or container level rather than relying solely on PHP’s own limit, together with keeping upload size limits low. This narrows exposure but does not remove it, and it is a job for whoever runs the server. Follow the wording in PHP’s official advisory.
• Web application firewall rules: Cloudflare announced WAF protection for these vulnerabilities. Treat a WAF as an extra layer, not a substitute for patching.

After you patch: check whether you were hit

Some exploitation is reported to have started before the fixes landed, so patching alone may be too late for a site that was already compromised.

1. Look for unexpected files in web-writable folders (uploads, cache, temp), especially new .php files with odd names.
2. Review web server and PHP logs since about 20 October for unusual requests and for spikes in out-of-memory errors or PHP fatal errors.
3. Check for new admin users, scheduled tasks (cron) and modified core files.
4. Compare files against clean copies of your CMS, plugins and themes.
5. Rotate secrets (database passwords, API keys, salts, SSH keys) if you find anything suspicious, and restore from a known-good backup rather than cleaning by hand.

A quick checklist

• Inventory every PHP install, including appliances, panels and containers
• Update to 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 (or a vendor backport)
• Restart PHP and verify the running version
• Apply temporary mitigations on anything you cannot patch immediately
• Hunt for web shells and unexpected changes
• Rotate credentials if there is any sign of compromise
• Move off PHP 8.1 and older, and plan for 8.2’s end of security support

What this teaches us

The PHP Foundation noted that its first external security audit in years, carried out in 2024, helped surface early signs of the memory problem behind CVE-2026-109618. The lesson for everyone running PHP is the familiar one: keep the runtime itself on a supported version and patch it as quickly as you patch your apps.

Sources

• The PHP Foundation: “Today’s PHP Security Release, and How We’re Strengthening PHP Security”
• Help Net Security: “PHP2Shell: Critical PHP vulnerabilities patched, update now!”
• Qualys Threat Research: “PHP Announces Critical Security Release for Two Vulnerabilities”
• Patchstack: “Major security alert: PHP vulnerable to critical RCE, attacks ongoing”
• Brandefense: “PHP2Shell: Two Critical PHP Flaws Reported as RCE”
• Codeable: “PHP Security Release on 21 October 2026: What WordPress Site Owners Need to Do”
• UK NCSC: “Critical security issue affecting PHP”

Details are still developing. Always confirm affected versions and mitigations against PHP’s official advisories (GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp) before acting.