Last updated: October 21, 2026. This is a developing story. Details marked unconfirmed come from early reporting and may change once the official PHP advisories are fully published.
PHP2Shell is the name given to two critical remote code execution vulnerabilities in the PHP core: CVE-2026-109618 and CVE-2026-109619. Both are rated CVSS v4.0 9.2. One unauthenticated HTTP request can trigger them, before any application code runs. Because the bugs sit in PHP itself and not in a framework or plugin, almost every PHP site on the internet is in scope, including WordPress, Laravel, Drupal, Magento and custom applications.
This guide explains what we know about PHP2Shell, which systems are affected, and how to patch, verify and detect it.
What Is PHP2Shell?
PHP2Shell is a pair of memory-safety bugs in how PHP handles the lifecycle of a web request. The name was coined in public reporting by the researcher 0x4148, following the tradition of Log4Shell and Shellshock. On October 20, 2026, the PHP security team posted an advance notice. Details of the flaws then leaked before the coordinated disclosure, so PHP shipped emergency releases on October 21, 2026.
| CVE-2026-109618 | CVE-2026-109619 | |
|---|---|---|
| Bug class | Memory corruption after out-of-memory (OOM) | Stale global state reused across requests |
| Impact | Unauthenticated RCE | Unauthenticated RCE |
| CVSS v4.0 | 9.2 (Critical) | 9.2 (Critical) |
| Auth required | No | No |
Why PHP2Shell Matters
- Huge attack surface: PHP still powers most of the web, and every SAPI that serves web requests is affected.
- Pre-application trigger: The bug fires during request handling, before your code runs. Input validation, WordPress security plugins and framework middleware cannot block it.
- Leaked before patch: Attackers had details before defenders had fixes, which shortened the patch window.
- Fast weaponization: Sansec expects mass exploitation shortly after release through patch diffing. Wiz researchers noted that frontier AI models lower the barrier to building a working exploit.
- Decades-old code: Early reporting says the flaws exist in every release from the PHP 5 era onward (unconfirmed). That would put many legacy and unmaintained servers at risk.
Technical Root Cause
The PHP project has published only a high-level description. Here is what is known about each bug.
CVE-2026-109618: OOM During Request Initialization
An out-of-memory condition can interrupt PHP while request data is only partly initialized. The request cleanup routine then treats that half-built data as if it were valid. Working on invalid pointers or structures during cleanup leads to memory corruption that can be turned into code execution. Some reports describe it as a heap use-after-free (unconfirmed). watchTowr says it has reproduced this bug.
CVE-2026-109619: Stale State Between Requests
PHP worker processes (for example in PHP-FPM or mod_php) are reused across many requests. Some request-owned internal state can survive after the memory behind it has been freed. A later request on the same worker may use that stale state before the normal initialization resets it. That is a classic use-after-free pattern across request boundaries.
Key takeaway: Both bugs live in the request lifecycle (startup and shutdown), not in any specific PHP function your code calls. That is why application-level defenses do not help.
Affected Systems
Any PHP installation that serves web requests is affected:
- Apache + mod_php (reported as the highest-risk setup)
- PHP-FPM behind Nginx, Apache or Caddy
- php-cgi
- FrankenPHP
- LiteSpeed (LSAPI)
PHP CLI scripts that do not serve web traffic are not the main exposure.
Fixed Versions
| Branch | Fixed in | Notes |
|---|---|---|
| PHP 8.5 | 8.5.12 | Supported |
| PHP 8.4 | 8.4.27 | Supported |
| PHP 8.3 | 8.3.36 | Supported |
| PHP 8.2 | 8.2.35 | Security support ends Dec 31, 2026 |
| PHP 8.1 and older | No upstream release | Minimal source backports exist for 7.4, 8.0 and 8.1. Some distributions and LTS vendors ship backports. |
Always confirm against the official php.net release announcement.
Linux Distribution Status
- Ubuntu 26.04 / 24.04 LTS: fixed through Ubuntu security updates.
- Ubuntu 22.04 LTS (PHP 8.1): upstream EOL, so the fix comes only from Ubuntu’s backport.
- Debian 13 / 12: fixed through Debian Security Advisories (DSA).
- Debian 11 (PHP 7.4): LTS ended Aug 31, 2026, so no packaged fix. Upgrade or isolate.
- RHEL / Rocky / AlmaLinux: check your enabled AppStream PHP module stream. Note that the Remi repository was reported as not having updates on release day.
- Docker: official
phpimages get rebuilt. You must rebuild and redeploy your own images. - Shared hosting / cPanel / Plesk: ask your provider to apply the update.
Important: distributions backport fixes without changing the upstream version number. A version string like 8.3.6 on Ubuntu does not tell you if you are patched. Check the package changelog instead (see below).
How an Attack Develops
- Reconnaissance: attackers mass-scan for PHP servers through headers like
X-Powered-By, file extensions, or known CMS fingerprints. - Trigger: a single crafted, unauthenticated HTTP request reaches the PHP worker.
- Memory corruption: the request lifecycle bug corrupts worker memory and leads to code execution as the web server user (
www-data,apache,nginx). - Post-exploitation: typical next steps are a web shell, a cryptominer, credential theft from config files like
wp-config.phpor.env, and lateral movement.
We do not publish exploit details here. Warning: be careful with “PHP2Shell PoC” repositories on GitHub. During high-profile CVEs, many fake PoCs contain malware aimed at the researchers who run them.
How to Check If You Are Vulnerable
1. Inventory PHP Packages
# Debian / Ubuntu
dpkg -l 'php*' | awk '/^ii/ {print $2, $3}'
# RHEL / Rocky / AlmaLinux
rpm -qa 'php*' --qf '%{NAME} %{VERSION}-%{RELEASE}\n'
dnf module list --enabled php
# Any system
php -v2. Confirm the Fix Is in the Changelog
# Debian / Ubuntu (adjust the package name to your version)
apt changelog php8.3-fpm 2>/dev/null | grep -E 'CVE-2026-10961(8|9)'
# RHEL / Rocky / AlmaLinux
rpm -q --changelog php-fpm | grep -E 'CVE-2026-10961(8|9)'If both CVE IDs appear, the installed package contains the fix.
3. Make Sure Old Workers Are Gone
A patched package on disk does nothing while old PHP workers are still running the vulnerable code in memory. Compare the FPM master start time with the package install time:
ps -eo pid,lstart,cmd | grep '[p]hp-fpm: master'How to Detect PHP2Shell Exploitation
As of October 21, 2026, watchTowr and Huntress have not reported confirmed in-the-wild exploitation, and neither CVE is in CISA KEV. Expect that to change quickly. Monitor for:
- PHP-FPM, php-cgi or Apache processes spawning shells, interpreters or download tools (
sh,bash,python,curl,wget). - Recon commands like
whoami,idoruname -arunning as the web server user. - Unexpected PHP worker crashes (segfaults) in logs. Failed exploitation attempts against memory bugs often crash workers.
- New or modified
.phpfiles in upload directories or web roots. - Outbound connections from the web server to unknown IPs.
Quick manual check for child processes of FPM pool workers (a healthy server usually prints nothing):
for p in $(pgrep -f '^php-fpm: pool'); do
ps --no-headers -o pid,user,lstart,cmd --ppid "$p"
doneCheck for segfaults in the logs:
journalctl -u 'php*-fpm' --since "2026-10-20" | grep -iE 'segfault|SIGSEGV|exited on signal'
grep -iE 'segfault|exit signal' /var/log/apache2/error.logIncident Response Workflow
- Contain: if you find signs of compromise, isolate the host from the network and keep it running for memory forensics if possible.
- Preserve evidence: collect web server access and error logs, PHP-FPM logs, process lists and recent file changes.
- Hunt for persistence: web shells, new cron jobs, SSH keys, new users and modified systemd units.
- Rotate secrets: database passwords, API keys, salts in
wp-config.php, and anything readable by the web user. - Rebuild: for a confirmed compromise, rebuild from a clean image rather than cleaning in place.
Mitigation and Validation
- Patch now to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your distribution’s fixed package.
# Debian / Ubuntu sudo apt update && sudo apt install --only-upgrade 'php*' # RHEL / Rocky / AlmaLinux sudo dnf upgrade 'php*' - Restart PHP so no old worker survives:
sudo systemctl restart php8.3-fpm # adjust version sudo systemctl restart apache2 # for mod_php - Rebuild containers from updated base images and redeploy.
- Validate with the changelog check and the FPM start-time check above.
- Interim WAF layer: Cloudflare has deployed WAF rules for known exploit vectors to all customers. Treat a WAF as a speed bump, not a fix.
- Partial workaround (one suspected path only): some vendors suggest disabling session upload progress until you can patch. This does not cover the second bug.
; php.ini session.upload_progress.enabled = Off - Cannot patch? The UK NCSC recommends taking unpatchable systems offline, or at least putting them behind a VPN.
Common Mistakes
- Updating the package but not restarting PHP-FPM or Apache. The old code keeps running.
- Trusting the version string on distributions that backport fixes.
- Forgetting containers, staging servers and old VMs. Attackers will find them.
- Relying on WordPress security plugins. The bug triggers before WordPress loads.
- Running random GitHub PoCs on your workstation.
- Assuming PHP 7.x is safe because it is old. Early reports say old branches are affected and receive no upstream fix.
Defensive Best Practices
- Keep an up-to-date inventory of every PHP runtime: hosts, containers, panels and appliances.
- Stay on a supported PHP branch. PHP 8.2 leaves security support on Dec 31, 2026.
- Run PHP-FPM pools as dedicated low-privilege users with separate pools per site.
- Use
disable_functionsforexec,system,shell_exec,passthruandproc_openwhere your apps do not need them, to limit post-exploitation. - Make web roots read-only for the PHP user where possible, and block PHP execution in upload directories.
- Restrict outbound traffic from web servers (egress filtering).
- Hide version banners with
expose_php = Offto slow down mass scanning.
Frequently Asked Questions
Is WordPress affected by PHP2Shell?
Yes, indirectly. WordPress itself has no bug here, but it runs on PHP, so any WordPress site on a vulnerable PHP build is exposed. Updating WordPress or plugins does not fix it. Updating PHP does.
Does PHP2Shell need authentication?
No. Both CVEs can be triggered by an unauthenticated remote request.
Is there a public exploit?
A working exploit has been demonstrated, and watchTowr reproduced CVE-2026-109618, but no trusted public PoC is available. Treat any “PoC” repository with extreme caution.
Is PHP2Shell exploited in the wild?
As of October 21, 2026, no confirmed in-the-wild exploitation was reported. Security researchers expect mass exploitation soon after the patch release.
I use shared hosting. What should I do?
Contact your hosting provider and ask when the patched PHP builds will be deployed. If your control panel lets you choose a PHP version, switch to a fixed release.
Conclusion
PHP2Shell (CVE-2026-109618 and CVE-2026-109619) is one of the most serious PHP vulnerabilities in years: unauthenticated, pre-application RCE in the core runtime, leaked before the patch. The response is simple but urgent: inventory, patch, restart, verify and monitor. Every hour an unpatched PHP server stays online is an hour attackers can use.