By Olivier Bilodeau, Cybersecurity Research Director

Update (as of October 29, 2026): As expected, the exploits have matured and two cybersecurity vendors have reported working reliable exploits for Apache/mod_php and nginx/PHP-FPM. Honeypots have also witnessed in-the-wild Apache/mod_php exploitation. More information in our Flare Intelligence report (in-platform).

Within hours of PHP2Shell (CVE-2026-109618 and CVE-2026-109619) going public, GitHub filled up with proof-of-concept exploits, and the underground went looking for one that works. We followed the PHP2Shell threads on Exploit.in, XSS, Dread, BreachForums and four other underground forums through the first 48 hours after disclosure.

The verdict from the most technical posters was blunt: the public PoCs crash PHP far more reliably than they pop shells. That verdict comes with a significant exception however: many appliances and embedded systems are likely to become exploitable because they are missing critical mitigation.

Key Findings About the PHP2Shell PoC Debate

• The most technical forum users say the public PoCs don’t work on real targets. The exploits need build-specific offsets from the target’s libphp.so, which can’t be known in advance or brute-forced.
• Forum users see the public code as AI-generated junk. “AI slop,” “vibe coded” and “copy-paster” are how they describe the GitHub PoCs.
• The barrier is one missing address, not a missing technique. A detailed test report on Exploit.in names the randomized base address of PHP’s code as the missing piece, and lists “a non-PIE build” as the fallback.
• Failed attempts still take sites down. A wrong guess crashes the PHP worker, and forum users treat that as a consolation prize.
• Systems without ASLR are where the barrier disappears. Security researcher reports that widely deployed appliances ship PHP with ASLR disabled. They should be first in line for patching.

“PoC Yes. RCE No.”

The PHP2Shell thread on Exploit.in opened with a simple question: does anyone have it? Within hours, the most experienced posters were pouring cold water on the excitement. One member, writing in English, summed it up in four words:

“AI will not handle this entirely for you. It is very complex. PoC yes. RCE no” — Ch4se, Exploit.in

Screenshot taken From Exploit.in of a user dismissing the public PHP2Shell PoCs

On XSS, a post celebrating the disclosure with “Wow, just wow” drew a sharper reply:

Screenshot taken from XSS of a user calling PHP2Shell “unexploitable” on real targets

“What exactly is the ‘wow’ here? In practice it’s unexploitable crap. To exploit real targets you need the offsets from libphp.so, which are unique to every build and impossible to brute-force. You can reproduce it on your own test bench, or if you already have access to the target’s filesystem.” — c0d3x, XSS (translated from Russian)

The next day, an Exploit.in member agreed: “In the lab, yes, it works. […] I haven’t seen anyone pull it off at scale yet.”

“Every PoC at This Point Is AI Slop”

The second complaint was about the code itself:

“Keep getting HEAP_LEAK_FAILED. I feel like every PoC at this point is AI slop that does not work properly” — Masamune, XSS

“Github is saturated with low quality vibe coded untested exploits.” — Flaw0, PwnForums

Screenshot taken from XSS of a user reporting that public PoCs fail

Exploit.in’s administration has the same problem. On October 19, two days before the fixes shipped, the admin wrote that the forum’s own bug bounty program had “run into a huge amount of neuro-slop” (AI-generated junk reports).

The Missing Piece to the PHPocalypse is One Address

The clearest technical explanation for why we don’t see mass exploitation came from an Exploit.in member who tried to write a PoC:

“Too much hype. […] It all comes down to offsets you can’t know in advance. […] All current exploits (including the one from Wiz) are made for lab conditions, where the offsets are known in advance. […] If you don’t guess the offset on the first try, you’ll bring PHP down. This is far from a ‘magic button’ for hacking any PHP site.” — XDev, Exploit.in (translated from Russian)

Screenshot taken from Exploit.in of a user explaining why public PoCs only work in the lab

The most rigorous post was a structured “mini-report” from astrotrain on Exploit.in, with self-reported results against patched and unpatched builds. It records crashes on 8 of 8 attempts against PHP 8.4.26 and none against 8.4.27, and working RCE through a session file when the server is misconfigured. The posts’ conclusion clearly explains why we don’t see mass exploitation of PHP in the wild.

“What’s missing: the PIE base. We have the heap, not the code. […] ‘Clean’ pre-auth RCE on a default setup runs into PIE. Fallback: a non-PIE build.” — astrotrain, Exploit.in (translated from Russian)

Screenshot taken from Exploit.in of a user’s structured test report on PHP2Shell

In plain terms, the exploit needs to know where PHP’s code sits in memory. ASLR and position-independent executables (PIE) move that code to a random address on every start, so it has to be leaked first, and that leak is the step astrotrain couldn’t solve. On a build where the address doesn’t move, there is nothing to leak.

The other half of the formula has a similar gap. Offsets are unique per build, but a stock build is the same everywhere it runs. On Exploit.in, members were already reposting offsets for packaged LiteSpeed builds. Outside the forums, the author of one public repository claims a one-shot RCE chain against the official php:8.4.26-apache Docker image.

Even the Skeptics Say It Crashes Sites

“It’s exploitable in this scenario: a sysadmin gets fired but decides to take revenge. Two ways: 1) If the libphp.so file is there, get RCE. 2) If it isn’t, crash the site 😂” — XDev, Exploit.in (translated from Russian)

Attempts that never achieve code execution can still knock an unpatched site over, but every failed attempt leaves crashed PHP workers behind, and that is a signal worth alerting on.

A $10K Budget and a Thread Full of Laughter

Not everyone was deterred. Exploit.in member SafeHarbor offered a “$10k budget” for anyone who could build a working exploit, said they were preparing “a list of targets and monetization methods,” and promised “more than $1M a week, minimum” if it worked.

Screenshot taken from Exploit.in of a user offering a $10,000 budget for a PHP2Shell exploit

The thread was not impressed:

“If it were possible, it definitely wouldn’t cost 10k. And of course ‘we’ll make more than $1M a week minimum’ 😂” — Insider, Exploit.in (translated from Russian)

The appetite is real, though. Earlier in the same thread, another member called PHP2Shell “a golden key”: whoever has working RCE now “will be working the internet until they drop, until public exploits appear.”

The Underground Is Patching Too

PHP2Shell is also a problem for the underground’s own infrastructure. On the morning the fixes were due, an Exploit.in member filed an urgent request in the forum’s own bug bounty thread: “The fix for CVE-2026-109618 and CVE-2026-109619 needs to go in very urgently.” Support replied within the hour: “We’re already working on it.”

Screenshot taken from Exploit.in of a user asking the forum to patch PHP2Shell

On Dread, administrator Paris posted a PGP-signed update:

“I’m getting really [expletive] tired of needing to redeploy core in what seems like every other week now. […] We use PHP for the core. […] There is tons of isolation, containerization, and process jailing, but you can only do so much when the dependencies you count on are vulnerable themselves.” — Paris, Dread

Screenshot taken from Dread of the forum administrator announcing an emergency redeploy

Where the Barrier Disappears: Systems Without ASLR

The forum consensus holds for a typical, modern, ASLR-enabled PHP build. It doesn’t hold for systems where PHP’s code sits at a fixed address. Those systems hand attackers the piece astrotrain says is missing, and they tend to run identical builds on every unit in the field.

On October 22, Kevin Beaumont reported exactly that kind of system:

“Also hp system management homepage (installed on HPE Proliant servers) all ship with PHP.. with no ASLR. There doesn’t appear to be a patch for that, you can use it to surf around flat networks as it drops you as SYSTEM/root.” — Kevin Beaumont, October 22, 2026

Earlier in the same thread, he says the same about the Palo Alto Networks firewall VMs (“ASLR disabled which makes exploitation trivial”) and Citrix NetScaler, particularly where the management interface faces the internet.

Appliances, management interfaces and embedded systems are often the last things patched, and they’re rarely monitored like web servers. For PHP2Shell, they are where “PoC yes, RCE no” stops being true.

What Defenders Can Do Now

• Patch appliances and embedded systems first. Inventory everything that ships PHP: server management interfaces, firewall and ADC management planes, NAS, building systems. Apply vendor updates. Where none exists, take the management interface off the internet and isolate the device.
• Then patch everything else. Move to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Start with official Docker images and distribution packages, whose builds are identical everywhere, and restart PHP workers afterwards.
• Don’t rely on session.upload_progress.enabled=Off. The PHP project and forum users agree it doesn’t block both vulnerabilities.
• Restrict what PHP can execute. Defense-in-depth advice for AppArmor or SELinux profiles that stop PHP from spawning commands.
• Alert on PHP worker crashes. Bursts of segmentation faults or aborts from Apache, PHP-FPM or LiteSpeed workers are the likeliest footprint of a failed attempt.
• Hunt for default PoC strings. A PoC posted on Exploit.in sends the user-agents php2shell-109618 / php2shell-109619 and the multipart boundaries B7kQpoc618 / B7kQpoc619 unless modified. VulnCheck has published the php2shell-scan/109618 scanner user-agent.

In Closing

This is not over, as Bruce Schneier once said:

> Attacks always get better, they never get worse.

PoCs will get better in a matter of hours/days but it seems like we avoided the whole Internet catching on fire, this time.

For more on how much of the internet still runs unsupported PHP, see our PHP2Shell exposure analysis.

References

• Kevin Beaumont, Mastodon thread on PHP2Shell and ASLR-disabled appliances, October 20–22, 2026: https://cyberplace.social/@GossiTheDog/117486883716972165
• PHP Group, security release announcement, October 21, 2026: https://www.php.net/index.php#2026-10-21-5
• Wiz Research, “PHP2Shell: PHP RCE”: https://www.wiz.io/blog/php2shell-php-rce
• 9bie, php2shell-bypass-aslr-exp (GitHub): https://github.com/9bie/php2shell-bypass-aslr-exp