SECURITY researcher Bojan Zdrnja provides a cautious take on the recently discussed php2shell exploitability. After examining published proofs of concept (PoCs), he argues that building a universal, reliable one-click exploit is far from straightforward, and much of the released material appears to rely on artificial or unrealistic conditions.
The PoCs described in the article deliberately create heavy memory pressure (for example, sending 1001 small fields of about 3,000 bytes each plus a 12 MB last field) to trigger memory allocation failures when memory_limit is set to 8 MB. In real-world deployments, memory limits are commonly higher (often 128 MB), and many servers run multiple workers rather than a single prefork process. This raises questions about the practicality of a broad exploit.
Zdrnja outlines the staged complexity of an exploit as observed in demonstrations. Phase 1 allegedly leaks the Zend MM heap base to locate a 2 MB-aligned chunk base for HashTable calculations. Phase 2 aims to leak the libphp.so base address by exposing the zval_ptr_dtor pointer, which would defeat ASLR if the exact code offsets can be determined from the server’s libphp.so. The effectiveness of this phase depends on factors such as PHP version, distro, and compilation options.
Phase 3 would involve altering pDestructor to zif_system to trigger code execution, with a 14-byte command size limit. Given these prerequisites, Zdrnja notes that the exploitability remains constrained, though not impossible. He recommends disabling session.upload_progress.enabled as a precaution and monitoring for any updates addressing the current workaround.