PHP2Shell is two critical vulnerabilities in the PHP engine, CVE-2026-109618 and CVE-2026-109619, fixed on October 21, 2026 in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. On an unpatched server, an attacker without an account can run code or read server memory, whatever application runs on top. To fix it, update the PHP runtime itself, not just WordPress or your plugins, and restart every PHP process.
Treat it as urgent. Vercel reports that working public exploits are available and that exploitation attempts have been seen, and Cloudflare observed attack traffic after details leaked on October 20. This post reflects the advisories as of October 22, 2026.
What is PHP2Shell?
PHP2Shell is the name the researchers at php2shell.com gave to two related memory-safety bugs in core PHP. Both come from how PHP cleans up when a request fails partway through.
- CVE-2026-109618, out-of-memory corruption. If a request hits PHP's memory limit at the wrong moment, PHP can leave half-initialized data behind and later treat it as valid. On Apache with mod_php, this happens before any application code runs (GHSA-w8hw-w9fx-j79w).
- CVE-2026-109619, stale global state. A fatal error can leave a worker holding pointers to memory from a finished request. The next request handled by that worker can then use freed memory (GHSA-6wmf-4rv5-p3rp).
Because the bugs are in PHP, secure application code doesn't protect you. The researchers also showed that memory disclosure can leak passwords, tokens, API keys and certificates belonging to other requests or the server itself.
How serious is PHP2Shell?
The ratings differ by source, which has caused some confusion:
| Source | Rating |
|---|---|
| PHP's GitHub advisories | Critical, CVSS 4.0 score 9.2 for both CVEs |
| NVD (CVE-2026-109618) | 9.8, CVSS 3.1 |
| Red Hat (CVE-2026-109618) | Important, 8.1 |
| Pre-release posts on social media | 10.0, which the PHP Foundation says was wrong |
Red Hat rates it lower because its default PHP-FPM setup is harder to exploit. On Apache with mod_php that reasoning doesn't apply, and no rating here justifies waiting.
Which PHP versions are affected?
Every supported branch before these releases is affected:
| PHP branch | Vulnerable | First fixed release |
|---|---|---|
| 8.5 | below 8.5.12 | 8.5.12 |
| 8.4 | below 8.4.27 | 8.4.27 |
| 8.3 | below 8.3.36 | 8.3.36 |
| 8.2 | below 8.2.35 | 8.2.35 |
Older versions are affected too, back to PHP 5.4 according to the researchers and Vercel. For the end-of-life branches 7.4, 8.0 and 8.1, php.net published only minimal source backports, so get a fixed package from your distribution or long-term support vendor, or upgrade. PHP 8.2 itself reaches end of life on December 31, 2026.
Who needs to act: a check for every hosting setup
Who applies the fix depends on where your PHP runs:
| Your setup | Who patches PHP | What to do |
|---|---|---|
| Managed WordPress hosting | Usually the host | Ask the host to confirm in writing that PHP is patched for both CVE IDs and that PHP was restarted |
| Shared or cPanel hosting | The host, for the PHP versions it offers | Ask the same question, and switch your site to a patched version if the panel lets you choose |
| Your own server or VPS | You or your developer | Follow the check and patch steps below |
| Docker or Kubernetes | Whoever builds your images | Rebuild every PHP image from a fixed base image and redeploy |
| An agency or freelancer maintains the site | Them, if hosting is in their contract | Ask for the fixed version or package changelog line, per environment |
| Next.js or other non-PHP sites, for example on Vercel | Nobody, unless PHP runs behind them | Patch any PHP backend the site proxies to, per Vercel's bulletin |
The advisories confirm code execution on Apache with mod_php and on PHP-FPM, and rate FrankenPHP as likely affected, so treat every setup as vulnerable until patched. Also look beyond the main website: a blog on a subdomain, phpMyAdmin, Nextcloud, staging copies and cron workers all run PHP.
How to check if your PHP is patched
On Debian, Ubuntu and RHEL-family systems, php -v can mislead you. These distributions backport the fix without changing the version number, so a patched Ubuntu 24.04 server still reports PHP 8.3.6 (see Ubuntu's fixed package list). Check the package changelog for the CVE IDs instead:
# Debian and Ubuntu: prints the CVE lines if the fix is installed
zgrep -E 'CVE-2026-10961[89]' /usr/share/doc/php*-common/changelog.Debian.gz
# RHEL, AlmaLinux, Rocky and Fedora
rpm -q --changelog php-common | grep -E 'CVE-2026-10961[89]'
# Source builds and official php Docker images show the real version
php -v
# Every running container on a host
docker ps -q | xargs -r -I{} docker exec {} php -vNo output from the changelog check means the package doesn't have the fix yet. Check the servers that handle traffic first.
How to patch PHP2Shell
- Update PHP. Install your distribution's security update, or the fixed upstream release for your branch.
- Rebuild containers. Build images with
docker build --pulland redeploy them. Restarting an old container runs the old PHP again. - Restart PHP. Restart Apache, PHP-FPM and any long-running PHP workers, or reboot. Running processes keep the vulnerable code until they restart.
- Confirm the fix. Repeat the check above on the servers that serve traffic.
- Repeat everywhere. Do the same for staging, preview, admin tools and background workers.
If you can't patch today
The advisories list stopgaps that reduce exposure while you schedule the update. None of them is a complete fix:
- Set
memory_limit=-1, cap memory with a cgroupmemory.maxlimit instead, and restart every worker. Don't useRLIMIT_ASorRLIMIT_DATAfor this; they trigger the same vulnerable path. - Set
session.upload_progress.enabled=0. It blocks the session path of CVE-2026-109619, not the other paths. - On PHP 8.5, set
fatal_error_backtraces=0, which removes the trigger behind the confirmed exploit for CVE-2026-109619. - Lower
post_max_sizeandmax_input_nesting_level, and block multipart form requests at the web server if the site takes no uploads. - Keep provider firewall rules on. Cloudflare enabled its rules by default, including on the Free plan; on paid plans, confirm the managed ruleset is set to block. Vercel's rules apply automatically. Neither covers requests that reach your server directly.
Hiding errors doesn't help: the advisory for CVE-2026-109619 says display_errors and error_reporting settings don't protect against it.
Signs of a PHP2Shell attack, and what to do after patching
The researchers published signals that can point to exploitation:
- Unusually large or malformed
PHPSESSIDcookies in responses. - Multipart requests followed by memory-limit errors or repeated HTTP 500 responses.
- PHP workers crashing or restarting without a clear reason.
Seeing none of these doesn't prove you weren't attacked, because the bugs run below the application and its logs may show little.
Patching also doesn't remove anything an attacker already left behind. For any server that was unpatched and reachable after October 20, we recommend two follow-ups:
- Rotate the secrets PHP held in memory: database passwords, API keys, SMTP credentials and session keys. Our article on security mistakes in AI-built apps covers where these keys tend to end up.
- Look for shells started by the PHP worker, new files in the web root, new cron jobs and new user accounts. If you find any, restore from a known-good backup instead of cleaning in place, which is easier with a tested restore process.
What PHP2Shell shows about AI-found vulnerabilities
The vulnerable code sat in PHP for more than a decade. According to Wiz, frontier AI models made it feasible to chain the bugs into working exploits and adapt them across applications. Wiz says a single researcher did in a week what previously would have taken a team of specialists months.
The PHP Foundation describes the other side: 15 CVEs published since July 1, and more than 100 reports that were invalid, duplicates or not reproducible. The CVE IDs leaked two days before the planned release, and a demonstration video published by mistake sped up work on exploits. The Foundation found no working exploit at release on October 21. A day later, Vercel reports working public exploits.
The gap between disclosure and exploitation can now be a day or less. Three habits make that manageable:
- Keep an inventory of every runtime you operate, including containers and forgotten tools.
- Automate operating system and base-image security updates.
- Keep an emergency patch path that you have tested before you need it.
Our AI security and reliability services cover reviews of code and configuration, fixes, and an ongoing retainer.
Frequently asked questions
Does PHP2Shell affect WordPress sites?
Yes, if the PHP underneath is unpatched. The researchers demonstrated code execution on current WordPress, Drupal and Joomla images. Updating WordPress or plugins doesn't help; whoever runs the server has to update PHP.
Is a WAF enough to stop PHP2Shell?
No. Cloudflare and Vercel rules block known exploit patterns, and both providers still say to patch. Attackers adapt payloads, and direct requests to your server skip the firewall.
Should I rotate passwords and API keys after PHP2Shell?
Yes, if the server ran unpatched PHP and was reachable after October 20. Memory disclosure can expose secrets without any other sign of compromise.
Is my site affected if it doesn't run PHP?
Not directly. Check whether anything around it does, such as a blog, an admin tool or an API backend.