PHP2Shell: How a Stale Pointer in PHP's Session Handling Turns an Out-of-Memory Error into Remote Code Execution
PHP2Shell Deep Dive
A detailed walkthrough of CVE-2026-109618 and CVE-2026-109619, two PHP vulnerabilities that chain an out-of-memory condition with a use-after-free to achieve remote code execution. The author explains the stale pointer's origin in PHP's session and OOM interaction, then builds a four-stage exploit: triggering the OOM, reclaiming memory with a forged zend_string, leaking heap and code pointers to defeat ASLR, and finally forging a HashTable to hijack pDestructor. The writeup emphasizes heap grooming, calibration for specific PHP builds, and real-world friction.
PHP doesn't hand an attacker a stale pointer on purpose... no, PHP isn't that generous. That pointer is the result of a subtle flaw in how a legitimate PHP feature interacts with the error handling mechanism of the Zend Engine.
- djad04
I'm the one who wrote this.I originally tried submitting it here myself but without much luck so glad to see someone else shared it! Thanks for bringing it here.
also if anyone has another working PoC for that specific build I'd really appreciate if they could share it because looking at how the exploit works it does something that is not done on any other solution that i found for other builds, none of them hold the spot with a resize (key “1050” is sent twice) than make an intermediate buffer from the next field("1999") fall there.it’s the only approach I’ve seen that uses a repeated key like that.
I wonder whether there's a more direct way to achieve that as in the solutions for other builds. If there is, I think it would be interesting to compare the reliability of the different approaches based on the memory manipulation itself rather than how they reach the target
- t1234s
The most impressive this was chaining this exploit with another linux exploit to gain root access.
A week to go down in history.