- One SANS handler reviewed some public php2shell proofs of concept. They need an 8 MB memory limit and one worker, and phase 3 was not checked.
- The source does not say the exploits fail in the wild. Improved or private exploits may not share these limits, and a bypass of the current fix apparently exists.
- The diary advises session.upload_progress.enabled = 0 until the next update. It says nothing about side effects, so test before wide rollout.
One handler's read of a few exploits, with limits
When a flaw gets a name, many teams drop their plans and rush. A diary from the SANS Internet Storm Center, published October 23, adds a careful data point on the php2shell vulnerability. It is one handler's quick review, not a verdict.
Two facts frame it. First, the author reviewed only some of the published proof-of-concept (PoC) exploits. Second, the author says there apparently is a way around the fix that is available today.
The author wrote that everyone was "running around like crazy" the day before, the author included. Then the author read some of the published PoC code and says much of it is AI-generated "slop". The conclusion was that a universal, reliable, one-click exploit looks quite difficult, "unless I'm missing something". The author asked readers to send corrections.
The diary does not say the public exploits fail against real servers. It says they come with prerequisites that make reliability hard.
How the one sensible demo works
The detailed walkthrough covers a single PoC. The author judged it the only one that makes sense. It abuses PHP's session upload progress feature, which tracks file uploads inside a session.
The request carries PHPSESSID and PHP_SESSION_UPLOAD_PROGRESS fields. It also sends 1,001 small fields of 3,000 bytes each, which the author says create allocation pressure. A 12 MB field then follows. Because the demo sets PHP's memory limit to 8 MB, the diary says this guarantees a memory allocation fails.
The author notes that real setups usually use a 128 MB limit, which makes this step "a bit more demanding". The demo also runs a single-worker prefork setup. That is a mode where PHP handles requests in separate worker processes. With one worker, the next phase must land on it.
Real servers typically run several workers. The author says an attacker would have to occupy all of them, free one and catch it. The author is not sure how hard that is.
Where the demo leans on inside knowledge
Phase one leaks the start of a block of heap memory, which later calculations need. Phase two targets ASLR, a defence that randomises where code loads each time the server starts.
The exploit leaks a pointer to a function called zval_ptr_dtor. That function sits at a fixed distance from the start of the libphp.so library. So once the exploit knows that distance, it can work out where the library sits.
The distance varies with how PHP was built, the exact PHP version and the Linux distribution. The author calls the demos "cheating" here. They get the numbers by opening the library file on the machine they attack. A remote attacker would need to know them in advance.
The author presumes someone could compile a list for common distribution combinations. So this hurdle is a knowledge problem, not a server setting. Phase three swaps a destructor pointer, a pointer to the cleanup routine run when a data structure is freed, for zif_system to run a command of at most 14 bytes. The author did not thoroughly check this phase.
What this does and does not show
This is the publication's reading. The review shows that the public demos it examined rely on conditions that are hard to meet at scale. It does not show that working exploits are out of reach.
The author believes the researchers who found the flaw "know (much) more". Private or improved exploits may not share these limits. A published list of offsets could remove one of them.
The diary also points to a flood of public exploit code. That is the author's observation, not a measurement. In the publication's view, it implies a cost for defenders, who must read the code to learn which of it matters.
What to do and ask
The diary recommends setting session.upload_progress.enabled = 0 in PHP's configuration. That switches off the session upload progress feature the demo relies on. The author says it should help and should stay in place until the next update, because the current fix apparently can be bypassed.
The diary says nothing about side effects. Teams should test the change on applications that use upload progress before a wide rollout. That advice is the publication's own.
Leaders can put four questions to their teams:
Which of our servers run PHP, and who owns each one? Has the upload-progress setting been turned off on them? What are our memory limits and worker counts, and does anyone check them against published exploit conditions? Who reads the exploit code when a new flaw lands, and how fast?
The lesson is not to wait. A named flaw deserves a precise question: what could an attacker really reach on our servers? One handler's early read helps frame that question, but it does not answer it.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: SANS Internet Storm Center.
