Major PHP Vulnerability Leaked

The conversation centers on a leaked PHP exploit/PoC and how operators should respond. lorenzbrun and others suggested the posted PoC may not be the embargoed vulnerability; InvisibleUp cited a PHP developer saying it might be unrelated. Several people recommended immediate mitigations like blocking multipart/form-data at the web server (Mooty, bulatb, secabeen), using SELinux/AppArmor (InvisibleUp), or employing Cloudflare (ffritz, AdamTReineke), while nilslindemann and iambateman reported taking services offline. synack described the issue as a use‑after‑free leading to arbitrary code execution, but Mooty and others who read the PoC questioned whether it actually works, pointing to implementation details like Z_TRY_ADDREF that may prevent the described exploit. Questions about package updates and checksums were raised (TekMol, e12e).

A strong meta‑debate touched on provenance, disclosure, and style. hparadiz criticized the decision to announce with a short embargo window as irresponsible; idlewords and kalleboo warned that LLMs make quick weaponization more likely. Many commenters (shevy‑java, drum55, fwlr, groestl) complained the PoC site looked AI‑generated and was unreadable, while others defended or contextualized PHP: AndroTux argued PHP’s security issues are overstated, whereas minitech and himata4113 blamed PHP’s design and ubiquity for its frequent problems. The community thus split over whether the published PoC is credible, how urgently to mitigate, and whether the fault lies with PHP, disclosure practices, or the new ease of automated exploit-finding.