Cybersecurity

PHP2Shell: Could a Quick Fix Leave Your Site Exposed?

Eric Parker examines an unofficial proof of concept and the configuration advice circulating before PHP released its security updates.

22 October 20262 min read3 min listen

Listen to the audio analysis

Create your own

Written for builders and creators.

Eric Parker's PHP2Shell video was recorded before PHP released the official fixes. He questioned a circulating proof of concept and the configuration change promoted with it.

Editor's note

Why this matters now

A PHP2Shell workaround was circulating before the official patches, and Eric Parker doubted the proof of concept behind it. In his video on the disclosure, he warns that administrators could apply the suggested settings change and believe they had protected a server while the real vulnerability remained.

The recording captures the period before PHP published its fixes on 21 October. Those releases change the immediate advice, but Parker’s concern remains relevant to the temporary workarounds PHP now documents: each blocks a particular attack, with other ways to exploit the bugs still possible.

The source

What it says

Distilled from the original. The notes above and below are the editor's own.

Why Parker Distrusted the Unofficial Fix

Parker challenges a publicly circulated proof of concept, saying it fails to demonstrate the claimed attack. He also objects to promoting a settings change as protection on that basis. An administrator following that advice could keep a vulnerable application online with misplaced confidence in its protection.

The Official Workarounds Have Specific Limits

PHP’s later advisories explain exactly why some configuration changes help only partially. The out-of-memory flaw can be triggered when PHP hits its per-request memory limit. Removing that limit interrupts the confirmed attack, but an underlying allocation failure can still trigger the bug.

For the separate stale-state flaw, disabling session upload progress blocks confirmed session-related attacks. Other stale-state attacks remain possible. The setting has to apply before request parsing, and every worker must restart. A setting changed by application code takes effect too late for that workaround.

PHP released 8.2.35, 8.3.36, 8.4.27 and 8.5.12 on 21 October. They contain the fixes for both vulnerabilities. The recording’s recommendation to wait for a release belongs to the earlier disclosure period.

Older Applications Face an Extra Update Problem

Parker also raises the difficulty of securing applications whose PHP branch has left regular support. An upgrade can involve application compatibility work, while a maintained package supplier may provide a backported fix.

PHP’s current notice adds exceptional minimal source patches for 7.4, 8.0 and 8.1. These give people building from source another option, while those branches remain outside ordinary upstream support.

Editor's note

What to do with this

The official workarounds show how much a short recommendation to change a setting can leave out: which attack it blocks, when the setting takes effect, and which attacks remain possible. PHP’s released patches address the flaws themselves. That makes the maintainers’ update a much firmer basis for protecting a server than the unofficial advice Parker was reacting to.

The original

The PHP RCE is Insane

Eric Parker · 21 October 2026