PHP Discloses New RCE Bug, Plans Regular-Release Fix

In its advisory, the PHP Security Team said an application must set session.serialize_handler to php_binary or php_serialize in its configuration and then switch it to php at runtime with ini_set() before calling session_start(). Session upload progress must also remain enabled. Applications that never change the serialize handler at runtime can keep the feature enabled, the advisory said.

The team recommended setting session.upload_progress.enabled=0 until the next regular bugfix release to protect against this RCE vector, which it described as “unlikely.” The same setting was listed as a mitigation for CVE-2026-109619, so users who applied it for that vulnerability should keep it in place, the team said.

CVE-2026-109619 is one of two critical-severity RCE vulnerabilities recently discovered and dubbed “php2shell.” PHP is used to build websites and web applications, and some analysts claim roughly 70% of websites run PHP, including banking, education, healthcare, and government sites. The PHP Security Team was working on a fix, and a handful of security organizations knew about or were involved in the work. The organizations were told not to break the news before a patch was released, but information leaked, and Amazon Web Services’ team saw exploitation attempts four days before the patch was due.

A few hours before the release, the CEO of security outfit Chainguard published container images containing fixes for the flaws, breaking the embargo, TechRadar reported. The security community blamed him for what happened next: attempted exploits grew to a few hundred, then a few thousand, then into the millions in the hours after the patch was released. The PHP Security Team issued a “heads up” alert telling IT teams to prepare for the patch, which was scheduled for Oct. 21. Healthcare, government, and education companies across Europe preemptively shut down their websites as they waited for the fix, according to different sources cited by TechRadar, but few breaches actually happened.

Yotam Perkal, director of security research at Pluto Security, said exploiting php2shell does not appear trivial. “PHP2Shell doesn't seem trivial to exploit. I believe that part of the reason we’ve yet to see successful exploitation is that reliable code execution requires getting past ASLR, a memory protection that randomizes where code sits in memory,” Perkal said. “That's hard to do remotely, and most of the public PoCs floating around (many of them vibe coded) simply don't work reliably on real systems.”

Perkal said ASLR can buy security teams time but warned that exploits will improve and most PHP servers remain unpatched. “I wouldn't count on it staying that way, though. Exploits will get better, and most PHP servers out there are still unpatched, so teams should patch and restart their PHP workers now. But compared with all the drama before and after the release, real-world exploitation so far looks pretty limited,” he said.