Leaked ‘php2shell’ Bugs Force PHP Into an Emergency Patch Day
PHP shipped 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on Oct. 21 to fix two critical bugs nicknamed php2shell, after details leaked early. Code claiming to exploit them is already circulating.
PHP has shipped emergency fixes for two critical vulnerabilities in the language itself. On Oct. 20 the project gave advance warning of the release, and BleepingComputer reported that details had leaked ahead of the planned disclosure, with security firm watchTowr saying it had reproduced one of the bugs. On Oct. 21, php.net published PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 alongside a security advisory that tells admins to update now.
For defenders
CVEs: CVE-2026-109618 and CVE-2026-109619, nicknamed “php2shell”. The PHP security team rates each 9.2 under CVSS v4.0. watchTowr and a since-deleted Hacker News post put them at 10.0, according to BleepingComputer.
What the bugs are: PHP’s advisory describes CVE-2026-109618 as out-of-memory handling that can interrupt a request while data is half-initialized, so cleanup treats invalid data as valid. CVE-2026-109619 is request-owned state that survives after its memory is freed and can be reused by a later request on the same worker. Both can allow unauthenticated remote code execution, per PHP. watchTowr told BleepingComputer it believes PHP 5 through 8 are affected. GMO Flatt Security’s analysis ties the flaws to the session upload progress feature (ext/session) and cites reproductions under mod_php and PHP-FPM, and in WordPress, Laravel and Symfony setups.
Fixed: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released Oct. 21. PHP 8.1 and older no longer get official releases; PHP says minimal backports for 7.4, 8.0 and 8.1 are available for source builds. PHP 8.2 reaches end of life on Dec. 31, 2026. Distro and hosting packages may lag, so check yours.
Status: exploitation in the wild is not confirmed. watchTowr says it hasn’t seen any, per BleepingComputer. Flatt Security says code claiming to exploit the flaws began circulating online on Oct. 21, but it hasn’t verified that code. With fixes public, expect scanning to pick up fast. Attacks of this kind map to T1190 (Exploit Public-Facing Application) (Exploit Public-Facing Application).
Interim mitigation: PHP and Flatt Security both mention setting session.upload_progress.enabled = 0 in php.ini (not via ini_set()) and restarting all workers. PHP says updating is the only complete fix and that mitigations only reduce exposure. Turning it off breaks upload progress bars, but normal uploads keep working.
What it means for you
PHP runs a huge share of the web, including WordPress and most shared hosting. If you have a website, a blog or an online shop, there’s a good chance PHP is underneath it. These bugs could reportedly let an outsider run their own code on the server, which can mean a defaced site, stolen customer data or a server quietly working for someone else. If your host manages PHP for you, ask them whether they’ve applied the Oct. 21 update. If you don’t run a website, there’s nothing for you to do.
Do this now
- Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 now, or apply your distro’s or hosting provider’s packages as soon as they ship. Restart PHP-FPM or Apache afterward so the new binary actually loads.
- If you can’t update today and don’t need upload progress bars, set
session.upload_progress.enabled = 0in php.ini and restart all workers. Treat it as a stopgap, not a fix. - List every PHP install you own, including old containers, staging boxes and EOL branches like 8.1 and 7.x. Those are the ones that won’t get patched by default.
- Check that web server and PHP logs are being kept, and limit what the PHP service account and database users can reach, as Flatt Security recommends.