Which PHP version should you move to?
| Branch you run | Update to | Support status |
|---|---|---|
| PHP 8.5 | 8.5.12 | Supported |
| PHP 8.4 | 8.4.27 | Supported |
| PHP 8.3 | 8.3.36 | Security fixes only |
| PHP 8.2 | 8.2.35 | End of life on 31 Dec 2026 |
| PHP 8.1, 8.0, 7.4 | No official release | End of life; minimal source backports or distribution patches only — upgrade recommended |
| PHP 7.3 and older, 5.x | No fix | Upgrade required |
Timeline
- 17 Oct 2026 — Amazon Threat Intelligence records an exploitation attempt against its honeypots, four days before disclosure.
- 20 Oct 2026 — php.net announces an upcoming critical security release.
- 21 Oct 2026 — php.net publishes the advisory and releases PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
Why PHP2Shell is serious
Both bugs sit in how PHP handles out-of-memory conditions and cleans up state between requests. A crafted request can leave internal data half-initialised, and a later request handled by the same worker can reuse it — leading to remote code execution, and in one path to leaking worker memory through the PHPSESSID cookie.
The bug triggers before your application code runs, so WordPress security plugins and application fixes cannot block it. It affects every way PHP serves web traffic: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed.
Temporary mitigations if you cannot update yet
These reduce exposure but do not fix the vulnerabilities (Datadog Security Labs). Set them in php.ini or the FPM pool, not with ini_set() or .user.ini, and restart every worker.
- session.upload_progress.enabled=0
- On PHP 8.5: fatal_error_backtraces=0
- memory_limit=-1 set by the administrator (php_admin_value), paired with request-size limits at the web server or proxy and memory limits on the container
- Do not use RLIMIT_AS / RLIMIT_DATA process limits
- Enable your CDN/WAF rules (Cloudflare published rules for known exploit vectors) — a partial layer only
- Take systems you cannot patch offline or isolate them, as the UK NCSC advises
Signals worth checking in logs
No official indicators of compromise have been published. Useful signals (Wiz, Datadog):
- “Allowed memory size … exhausted” together with “Unknown on line 0” in the PHP error log
- Unusually large form fields or binary data in POST requests
- Repeated HTTP 500 errors, worker crashes or segmentation faults
- Oversized or malformed PHPSESSID cookies in responses
- A web worker (for example www-data) spawning a shell
How Uptech patches PHP2Shell
- Free check. We identify where each site is hosted, the PHP version actually serving web traffic and the risk level.
- Backup and shield. Off-server backups of code and databases; temporary WAF rules and settings while the update is prepared.
- Update or upgrade. Patch within the same branch, or upgrade PHP 7.4–8.1 after testing plugins, themes and custom code on a staging copy.
- Test and review. Key pages, checkout and forms are tested; servers are reviewed for signs of exploitation; a before/after report is delivered.
Uptech provides technical services (checking, updating and upgrading PHP); it is not the PHP project. Facts on this page come from php.net and the security researchers listed below. No measure guarantees absolute security.
Sources
- php.net — Security advisory: Critical remote code execution vulnerabilities (21 Oct 2026)
- php.net — PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 releases
- Wiz — PHP2Shell: critical RCE vulnerabilities in PHP
- Datadog Security Labs — PHP2Shell: detection, analysis and remediation
- Help Net Security — PHP2Shell: Critical PHP vulnerabilities patched
- Google Cloud — Responding to core PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619