PHP2Shell: The Critical PHP Flaw Every Website Owner Must Fix Now

On October 20, 2026, the PHP team announced an emergency: two critical holes in the PHP language itself that can let a stranger run their own code on your server — no password, no account, no clicking anything on your side. Patches landed October 21. If your website runs on PHP (WordPress, Drupal, Laravel, or anything custom-built), this post explains what happened in plain language, how to fix it today, and how to make your site a harder target from now on.

If you only remember one thing: update PHP to 8.2.35, 8.3.36, 8.4.27, or 8.5.12 (whichever line you run) right now. Updating is the only complete fix — everything else below buys time or builds habits.

What is PHP2Shell?

PHP2Shell is the nickname for two vulnerabilities disclosed together:

CVE-2026-109618 — remote code execution through corrupted memory handling. Scored 9.2 out of 10 (Critical).
CVE-2026-109619 — remote code execution through stale memory reuse between requests. Also scored 9.2 (Critical).

"Remote code execution" (RCE) is the scariest phrase in security: it means an attacker can run their programs on your server. "Unauthenticated" means they don't need an account — they just send specially crafted web requests. Combined, the two words mean: anyone on the internet could potentially take over an unpatched PHP website.

Both flaws live in PHP core — the engine itself, underneath WordPress, Drupal, plugins, and themes. That is why everyone is affected at once, and why updating your CMS alone is not enough: the engine underneath must be patched.

How do the flaws work? (Plain-language version)

You don't need to be a security researcher to grasp the shape of it. Both bugs are memory mix-ups — PHP losing track of what's what inside its own head:

Flaw 1: the interrupted cleanup (CVE-2026-109618). When PHP runs out of memory mid-request, it can abandon its work halfway — leaving half-built internal records behind. Then its own cleanup crew trips over those half-built records. Attackers discovered they can trigger this on purpose with crafted file-upload requests that exhaust memory while looking small enough to pass the configured limits. On some setups (notably Apache mod_php), the trap fires before your application code even runs — meaning no plugin, firewall rule inside your app, or careful coding can intercept it.

Flaw 2: the leftover note (CVE-2026-109619). To serve visitors faster, PHP reuses worker processes across many requests — like reusing a notepad. The bug: sometimes a note from an earlier visitor's request isn't erased, and a later request reads it. Through features that run very early (session handling and upload tracking, which are on by default), an attacker can plant and then exploit that leftover state — including triggering it with fatal errors and timeouts that interrupt normal cleanup.

Security researchers have demonstrated both attacks working in labs, and multiple parties report seeing exploitation attempts in the wild. Current public exploits only work in narrow conditions — treat that as a closing window to patch, not a reason to relax.

Who is affected?

Every setup that serves web requests with PHP: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed.
Highest risk first: Apache mod_php, because the attack can succeed before any of your code runs.
Supported versions with patches: PHP 8.2 (fix: 8.2.35), 8.3 (fix: 8.3.36), 8.4 (fix: 8.4.27), 8.5 (fix: 8.5.12).
End-of-life versions (8.1 and older, including the still-common PHP 7.x): no routine fixes — only limited source backports for 7.4, 8.0, and 8.1. If you run these, upgrading to a supported version is part of the fix.

One more thing, disclosed today

On October 23, 2026, PHP disclosed an additional session-related flaw, CVE-2026-115560, tied to session upload progress. Details are still emerging, but PHP's interim advice is the same knob you'll meet below: set session.upload_progress.enabled=0 until the next bugfix release. This is a developing story — check the official PHP announcements for updates.

How to check if you're affected

Two minutes, no expertise needed:

Find your PHP version. If you have server access, run:

php -v

Compare against the fixed versions above. Anything older on lines 8.2–8.5 is vulnerable; anything on 8.1 or older is both vulnerable and out of routine support.

No server access? Ask your host ("Which PHP version runs my site, and have the October 21 PHP2Shell patches been applied?"). Reputable shared hosts patched within hours — many auto-updated. Managed WordPress/Drupal hosts typically handle this for you; confirm rather than assume.
Know your setup. Ask the same host or developer whether you run mod_php or PHP-FPM. mod_php owners patch first — highest risk.

How to secure your PHP website

In order of urgency:

1. Update PHP now (the only complete fix)

Shared/managed hosting: open a ticket or check the panel — most hosts applied patches October 21–22. Verify with php -v or ask support to confirm.
Your own server (VPS/dedicated): update through your package manager or rebuild from the fixed sources, then restart every PHP worker (FPM pools, Apache) so no unpatched process keeps running. An update without a restart is a patch that isn't live yet.
Stuck on PHP 7.4–8.1: get a vendor fix, use PHP's published source backports, or — best — upgrade to a supported line. Staying on end-of-life PHP means the next critical flaw won't be fixed for you either.

2. Apply the emergency brakes (if you cannot patch immediately)

These reduce exposure; they do not replace updating. Apply in server configuration (not in app code — that's too late), then restart all workers:

Set session.upload_progress.enabled=0 (blocks the confirmed session-based attack paths).
On PHP 8.5, set fatal_error_backtraces=0.
Where uploads aren't needed, cap request sizes (post_max_size=8M); where needed, keep them tight (post_max_size=32M, upload_max_filesize below that).
If your app never accepts file uploads, block multipart requests before they reach PHP.

3. Harden the PHP installation itself

Do these once, benefit forever:

Hide the version. Set expose_php=Off in php.ini so PHP stops advertising its version in HTTP headers. Attackers scan the internet for version banners — don't hand them a list.
Lock down error output. display_errors=Off (visitors must never see stack traces), log_errors=On (you still want the logs, privately).
Disable dangerous functions your app doesn't need (in php.ini):

disable_functions = exec, shell_exec, system, passthru, popen, proc_open

These are the exact tools takeover attacks reach for. If your app genuinely needs one, allow only that one.

Fence PHP in. open_basedir restricts which directories PHP files can touch, so a breach in one site can't wander the whole server.
Vet file uploads. Accept only the file types you need, check contents (not just extensions), store uploads outside the web root or serve them without script execution.

4. Harden everything around PHP

Update the whole stack: CMS core (WordPress/Drupal), themes, plugins, and modules — attackers pivot to whatever is oldest. Turn on automatic updates where your host offers them.
Least privilege: the web user should write only where it must (uploads, caches) — never to its own code directories.
Strong, unique credentials + two-factor on hosting panels, CMS admins, and database users. Most "hacks" still walk through stolen passwords, not exotic flaws.
Backups you have tested: automated, off-server, with at least one restore drill. A takeover without backups is a ransom situation; with backups, it's a bad afternoon.
A firewall in front: a web application firewall (Cloudflare's free tier, ModSecurity, or your host's WAF) won't fix PHP2Shell, but it blocks the background noise of bots probing for it — and the next flaw.

How to avoid being a potential target

Attackers don't usually pick you — they sweep the internet for anyone vulnerable. Avoiding the sweep is practical, not paranoid:

Don't advertise. expose_php=Off, remove version banners from headers and footers ("Powered by X 1.2.3" is a menu for attackers), and keep admin login pages off obvious URLs where your CMS allows it.
Patch on a rhythm, not in a panic. Subscribe to your CMS security list and the official PHP announcements so October 21-style news reaches you in hours. The sites that got hurt worst by PHP2Shell were the ones that learned about it last.
Shrink what faces the internet. Every plugin, theme, exposed admin page, and open port is a lottery ticket you didn't mean to buy. Remove what you don't use; close what you don't need.
Stay on supported versions — of everything. PHP 8.1 and older get no routine fixes now. The same goes for old CMS releases. End-of-life software is a permanent bullseye.
Watch and log. Review access logs for odd bursts (especially upload endpoints), enable your host's malware scanning, and set up uptime/alerting so you notice defacement or outages before your visitors do.
Plan the bad day. Know in advance: who do you call at the host, how do you restore from backup, how do you force-reset all credentials? A one-page incident plan turns chaos into procedure.

Key sources

PHP announcement archive — October 2026 releases — the official word: affected versions, fixed versions, backports.
GHSA-w8hw-w9fx-j79w (OOM corruption advisory) — technical detail on CVE-2026-109618.
GHSA-6wmf-4rv5-p3rp (stale state advisory) — technical detail on CVE-2026-109619.
Rapid7 emergent threat response: PHP2Shell — exposure, exploit status, and mitigation analysis.
PHP supported versions — check whether your PHP line still gets fixes.
Drupal security — CMS-layer advisories for Drupal site owners.