PHP2Shell Explained: Who Is Affected and How to Secure WordPress

On 21 October 2026 the PHP project shipped fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Widely called PHP2Shell, this family of bugs can allow unauthenticated remote code execution (RCE) or process-memory disclosure on PHP servers that handle web requests. Each CVE is scored around CVSS 9.2. Almost every PHP web install is in scope — including WordPress, Drupal, Joomla, Laravel and shared hosting.

The key point for site owners: updating WordPress, themes or plugins does not fix this. You must upgrade the PHP runtime itself to a patched release and restart workers. This article summarizes the situation, affected versions and concrete remediation steps for WordPress and similar PHP CMSes and apps.

What is PHP2Shell?

Both CVEs live in PHP’s core memory and fatal-error handling, not in any one CMS:

• CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): memory corruption during out-of-memory (OOM) handling. If a request hits memory_limit at the wrong moment, PHP can leave partially initialized internal data that cleanup later treats as valid, opening a path to code execution. On Apache with mod_php, RCE was demonstrated before any application code runs.
• CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): stale global state across requests. After a fatal error, internal state may still point at freed memory; a later request on the same worker can abuse that use-after-free.

Researchers at Wiz, Calif and OpenAI Codex Security reported the issues. Wiz notes that PHP powers roughly 70% of websites and demonstrated pre-auth RCE against WordPress, Drupal and Joomla container images. AWS reported exploitation attempts from about 17 October 2026 — days before public disclosure — and broader exploitation after the patches shipped.

Who is affected?

• Vulnerable: PHP 8.5 before 8.5.12, 8.4 before 8.4.27, 8.3 before 8.3.36, 8.2 before 8.2.35.
• Fixed: 8.5.12, 8.4.27, 8.3.36, 8.2.35.
• PHP 8.1 and older: end-of-life. Upstream does not fully support those branches; some vendors shipped backports. CISA, the UK NCSC and WordPress advise taking unpatched internet-facing systems offline until they can be upgraded.
• Runtimes: PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed and other web workers. mod_php is called out as highest risk.
• Applications: any PHP web script, including a Hello World app. WordPress, Drupal, Joomla, WooCommerce, Laravel, Magento and hosting panels that embed PHP.

WordPress.org stated clearly that these flaws are not WordPress-specific and that no WordPress core update is required or planned — only the PHP runtime must be updated.

Urgent checklist for WordPress

1. Read the exact PHP version: in wp-admin go to Tools → Site Health → Info → Server → PHP version. “8.3” is not enough; you need the patch level (for example 8.3.36).
2. If you are below the fixed numbers: in your host panel (cPanel MultiPHP, Plesk, Hostinger PHP Configuration, SiteGround PHP Manager, etc.) move to a supported branch and ask support whether their build includes CVE-2026-109618 and CVE-2026-109619. Some hosts backport the fix without changing the visible version string — written confirmation matters.
3. Restart workers after the update (PHP-FPM, Apache, LiteSpeed). Old workers keep serving the vulnerable binary until they are recycled.
4. Docker: rebuild images from a base that includes patched PHP; restarting an old image is not enough if the old binary is baked in.
5. WAF: Cloudflare, AWS WAF and many hosts deployed temporary rules. A WAF helps but is not a substitute for patching.
6. On PHP 8.1 or older: back up, test plugin compatibility with PHP 8.3+, and migrate. PHP 8.2 security support ends 31 December 2026; plan for 8.3 or newer.

Practical steps on your own VPS

Update PHP packages from your distro or vendor repository, then restart the web stack. Example for apt-based systems (adjust package names to your repo):

# Current version
php -v
# And for the real FPM binary (may differ from CLI):
# php-fpm8.3 -v

sudo apt update
sudo apt install --only-upgrade php8.3-fpm php8.3-cli
sudo systemctl restart php8.3-fpm
# If you use Apache mod_php:
sudo systemctl restart apache2

Confirm the web server loaded the new binary:

curl -sI https://yoursite.example/ | head
# Or a temporary phpinfo page — delete it immediately after reading the version

Temporary risk reduction (until you patch)

No mitigation fully closes the hole, but you can shrink exposure:

• Restrict public access or, per CERT-EU / CISA guidance, isolate internet-facing apps until patched.
• For known CVE-2026-109619 paths: set session.upload_progress.enabled=0 in php.ini or the FPM pool, and on PHP 8.5 also fatal_error_backtraces=0 where possible, then restart every worker.
• WAF / reverse-proxy rules in front of PHP to block abnormal form bodies (extremely long field names, control bytes in POST).
• Tighten body size and rate limits in nginx/Apache.
• Keep allow_url_include off and restrict dangerous functions (exec, system, passthru, shell_exec, etc.) via disable_functions — these are not a patch substitute, but they reduce blast radius after a foothold.

Datadog stresses that tricks such as disabling upload progress alone do not fully protect you. Patching PHP is the only complete fix.

After patching: monitor and clean up

• Watch PHP logs for Allowed memory size ... exhausted with location Unknown on line 0, and for worker segfaults.
• Treat any shell spawned under the web worker (www-data, nginx, apache) as suspicious.
• If the site was internet-facing before the patch, rotate passwords, API keys, WordPress salts and tokens — memory disclosure can leak secrets even without full RCE.
• Review wp-content for unknown plugins/files, odd cron jobs and new admin users.

Bottom line

PHP2Shell is one of the most serious web security events in recent years because it sits in the PHP engine itself and application authentication cannot stop it. For WordPress and similar CMSes the path is clear: check the exact PHP version → upgrade to 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 or your host’s patched build → restart workers → keep the WAF but do not rely on it alone → rotate secrets if you suspect exposure.

Primary sources: CISA alert (21 Oct 2026), PHP Foundation announcement, wordpress.org security news, and reports from Wiz, Datadog, AWS and CERT-EU.