logoalt Hacker News

PHP2Shell: AI uncovers critical RCE in PHP

404 points • by danlark1 • today at 1:43 PM • 151 comments • view on HN

https://www.php2shell.com/


Comments

fwlr • today at 4:03 PM

So from what I gather, it was found by OpenAI (via unspecified model?) and independently by Wiz (via Gemini Argon)… but before that it was found by Calif (via unspecified but consumer-available model)… but Calif credit LCFR_HAX before them with first discovery, disclosure, and remediation efforts.

I guess either LCFR or Calif put it in the training data (by using a consumer-available frontier model in the process of discovery or remediation), and then OpenAI reproduced it from the training data, Navier-Stokes-scoop-style? Except I guess more plausibly unaware, and also late? They thought they had something novel, because they weren’t privy to the existing remediation effort? It’s all rather confusing, and then on top there’s a leak and a PR campaign and it just becomes impossible to untangle.

edit: thank you PHP foundation for making this all make sense https://thephp.foundation/blog/2026/10/21/todays-php-securit...

➕ show 4 replies
Topfi • today at 2:21 PM

Can anyone explain the two month window between reporting and disclosure? I do understand Responsible Disclosure as a concept, but looking at the timeline and severity, I struggle to understand the timing, especially the month that passed before an acknowledgment.

Edit: Apparently this had been reported more than half a decade ago [0]. I am getting more confused the more I look into this, hopeful for a well written, factual post-mortem from someone who hasn't actively avoided PHP for the last decade.

[0] https://news.ycombinator.com/item?id=50181395

➕ show 4 replies
airtnp • today at 2:52 PM

Ok, based on my reads on Wiz and Calif writeups, there are 5-6 issues mapped to 2 CVEs.

Wiz (with GPT 5.6 Sol + Gemini 4 Argon) : Remote process-memory disclosure; OPcache type confusion; Fatal-error backtrace UAF. POC on Wordpress, Drupal and Joomla

Calif (with LLM, no specific model, but model is accessible to all): Zend HashTable OOM. Targets PHP-FPM and mod_php.

Both discovers the UAF on upload progress unserializer.

Surprised to see the anime girl dancing with POC is really uploaded by Calif researchers.

➕ show 4 replies
edh649 • today at 2:28 PM

Seems to have been prompted from research by calif.io who started disclosure on August 11 vs Wiz on August 24th? A bit unclear on the participants and how they all interacted... https://calif.io/php2shell/

➕ show 2 replies
WJW • today at 3:40 PM

From the related article on calif.io:

> We therefore control where PHP places a pointer and its associated type information. This is application-dependent RCE under both Apache mod_php and PHP-FPM.

Both articles describe how you can end up with freed memory that still has pointers into it. I can understand that this should never be possible, but it seems to me that both articles skip the very important step of how to actually turn this into RCE?

From my (admittedly limited) understanding of these things you would not only need to write arbitrary memory, but also need to be able to jump to the relevant address to execute such things. Or do they overwrite the PHP (byte)code with their own and then just let the interpreter do its thing?

➕ show 2 replies
pettijohn • today at 2:04 PM

Silly question, is PHP part of Project Glasswing? Crazy this has been dormant for a decade. And scary to wonder what else is lurking out there.

➕ show 2 replies
tchalla • today at 2:10 PM

> We used Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol throughout this research. Notably, Gemini 4 Argon made an invaluable contribution to finding the vulnerability, exploit development, attack detection, and validation of the patch.

➕ show 2 replies
wildmXranat • today at 2:49 PM

Did anyone find a reputable source for code which can be used to validate fixes ?

ang_cire • today at 3:34 PM

> PHP powers approximately 70% of websites,

Well, that's my depressing statistic for the day...

➕ show 5 replies
zelphirkalt • today at 6:04 PM

And just a while ago, I decided against hosting a PHP-based forum service, and instead build my own. Feeling vindicated today.

chasil • today at 3:35 PM

Does active SELinux (as used in Red Hat derivatives) limit the damage at all?

I built some rhel7 systems that are relaying user-provided LDAP credentials into a domain controller, and these are probably wide open with these flaws.

I would hope that SELinux would prevent the launch of a shell, at least.

Does PHP built with FORTIFY_SOURCE and other RedHat-recommended compiler flags help?

➕ show 1 reply
rbanffy • today at 3:51 PM

Maybe a silly question, but is there any full-featured CMS suitable for large-ish organizations that's been undefeated in terms of security? The only one that comes to mind is Plone (which is used extensively in the Brazilian government), but there has to be more.

➕ show 1 reply
schleck8 • today at 3:49 PM

Looking at the technical deep dive further down the article, this is worse than Log4Shell if you need a point of reference. It's one of the two worst exploits that ever publicly surfaced, up there with EternalBlue.

➕ show 1 reply
asbv-1qq • today at 2:16 PM

The flaw was in at least 20 year old code, which seems to be a common theme for AI discoveries.

No compute costs for finding the issue or for writing the exploit are disclosed.

But it is marketed as if it were the first RCE found in human history.

➕ show 5 replies
jongjong • today at 2:49 PM

Damn. I've been saying that writing correct software is almost impossible.

I suspect it's a matter of time before all mainstream blockchain projects are cracked. Many of those projects are hundreds of thousands of lines of code. There's no way they don't have vulnerabilities given that AI is now uncovering so many vulnerabilities in such high exposure projects.

I was a code minimalist before, now I'm a radical minimalist. We need to get the lines of code down to the absolute minimum.

Attack surfaces need to be clearly defined, enumerable and testable under all possible conditions.

➕ show 1 reply
sehw • today at 2:05 PM

Ye, no humans but "AI".

➕ show 3 replies
ascii0eks84 • today at 5:32 PM

To be honest nobody should be surprised. PHP is a wormhole of sorts.. can of worms.

eptcyka • today at 3:12 PM

I guess I should update my nextcloud.

No, scratch that. I should replace it with something that is not a trash fire.

➕ show 2 replies
mg794613 • today at 2:46 PM

I'm so tired of some of these "research setups", do you really need a logo, a brand and everything setup so you can cash in? Was this truely a problem or artificially created?

Especially after fumbling it like this.

"Buy our product, because we found a bug", yeah and you leaked it too.

NooneAtAll3 • today at 2:51 PM

Ai fumbles responsible disclosure*

azyc • today at 6:42 PM

[flagged]

simonw • today at 2:16 PM

Timeline from that article:

August 19, 2026: Wiz Research discovers the first PHP vulnerability using Wiz Atlas, Gemini 4 Argon, and GPT-5.6 Sol.

August 20, 2026: Unauthenticated RCE is confirmed against Drupal.

August 21, 2026: Unauthenticated RCE is confirmed against WordPress.

August 24, 2026: Wiz Research reports the vulnerabilities to the PHP security team.

September 21, 2026: PHP acknowledges the reports and begins developing a coordinated fix.

October 21, 2026: Patched PHP releases become available.

October 21, 2026: Public disclosure.

I want to understand how it leaked. I guess a whole lot of people were looped in between September 21 and October 21?

➕ show 7 replies
wren6991 • today at 3:07 PM

Did an LLM do the write-up? Half of the "technical deep dive" was just re-stating earlier statements about scope and impact, and I left without a solid grasp of the mechanics of the exploits.

➕ show 2 replies
chinathrow • today at 2:19 PM

[dead]

Jeeetendra • today at 3:45 PM

[flagged]

varispeed • today at 3:31 PM

If AI "uncovered" it, that means it was already in the training data and likely exploited in the wild.

➕ show 2 replies