PHP2Shell: AI uncovers critical RCE in PHP (wiz.io)
fwlr 4 days ago
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...
ToValueFunfetti 4 days ago
[1]https://www.scientificamerican.com/article/openais-blockbust...
nh23423fefe 4 days ago
fwlr 4 days ago
Naturally, with the added info from the PHP foundation link (specifically that OAI reported it the same day as Calif, and that Calif was operating under the auspices of an OAI program) the timeline collapses for my initial impression!
magnat 4 days ago
What a coincidence.
hashstring 4 days ago
How does this work? Calif works with OAI on Patch the Planet program. Calif reports the finding to PHP. OAI ‘independently’ reports it too, on the same day. I suppose Calif did communicate with OAI about said findings, or is this not how Patch the Planet operates? It seems extremely coincidental.
fma 4 days ago
WarmWash 4 days ago
dspillett 3 days ago
Topfi 4 days ago
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.
phoronixrly 4 days ago
phoronixrly 4 days ago
> On October 21st at 07:41 UTC, more than six hours before the coordinated release, Chainguard unilaterally broke the embargo and published built images containing the fix. Like other distributors, Chainguard had received the patch in advance so its users could update the moment the vulnerabilities were disclosed. Any attacker could now study the fix in binary form while every other PHP user was still waiting for the release. This disregarded weeks of work by many parties toward a coordinated disclosure.
kylestanfield 4 days ago
blantonl 4 days ago
dspillett 3 days ago
From what I read last night: that patch fixed a specific case (an over-large index that became a negative number) that could trigger the problem, but did not fix the core problem itself. The new exploits try to trigger the problem in another manner, the new patch does address the core issue.
varispeed 4 days ago
AtNightWeCode 4 days ago
Topfi 4 days ago
AtNightWeCode 4 days ago
Topfi 4 days ago
utternerd 4 days ago
AtNightWeCode 4 days ago
Is this HN or boomer FB? I don't know anymore.
airtnp 4 days ago
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.
airtnp 4 days ago
https://github.com/php/php-src/commit/712e60f9edfd03f0960fc4...
processunknown 4 days ago
airtnp 4 days ago
echoangle 4 days ago
nicce 4 days ago
klausa 4 days ago
echoangle 4 days ago
nicce 4 days ago
After all, furries run the internet.
owenmarshall 4 days ago
I was griping about my day being ruined over the breakfast table and my son was interested. I showed him the video and he asked why there was an anime girl on the screen?
My response was "if you've worked with computers for any length of time, and you ever see a video of a terminal posted with an anime, catgirl, or furry overlay, you know something really bad is coming your way."
cowlevel 4 days ago
lenerdenator 4 days ago
And how's that going?
solyin 4 days ago
lenerdenator 4 days ago
jareklupinski 4 days ago
sounds like a good time
throawayonthe 3 days ago
chuckadams 4 days ago
rbanffy 4 days ago
This is why languages like Rust have their place - their compilers impose the discipline and the restraint C doesn't. It's not impossible to write code with memory safety issues in Rust - it's just a lot harder. I remember saying the same about Java - it doesn't make writing the program any easier, but it makes writing some bugs difficult.
Ar-Curunir 4 days ago
chuckadams 4 days ago
"Make no mistakes" works about as well for humans as it does for AI, and we have decades of lived experiences to draw on for that verdict.
rbanffy 4 days ago
chuckadams 4 days ago
rbanffy 3 days ago
There is a catch, however. Some languages will not allow you to take some shortcuts you know are safe unless you can prove them safe.
UncleMeat 4 days ago
It isn't like C has some "there be dragons" set of features that are hard to use. The source of exploitable memory safety issues is consistently just foundational language features.
tialaramex 4 days ago
Go look at a nineteenth century mechanical signal box. When you, through inattention or even malevolence, try to release signals so that train B can plough into train A, the lever won't move because it is physically impossible due to mechanical interlocking, you need to move a piece of sold metal through another piece of solid metal and it won't go.
Do not rely on humans to do boring but important things, they are very bad at this.
kstrauser 4 days ago
It sure is to blame. Evidence shows you need wisdom, discipline, and an impossibly high bar of encyclopedic knowledge of every feature of C and all common libc's combined with an inhuman perfection of never once making a single typo, and a vast amount of tooling to analyze the code and find some of the bugs that made it through anyway.
The best, most trusted, most accomplished C programmers I could name still have a track record of writing vulnerabilities triggered by C footguns, not just garden variety logic bugs that could affect code written in any language. Can I write more diligent C code than the OpenBSD team? Than the Linux devs? Than Fabrice "I made everything" Bellard? Not a chance, but C has bitten each of them. Us mortals don't stand a chance.
rbanffy 4 days ago
I'd say it's just a matter of moving in shorter steps, test incrementally, use extensive tooling to poke holes at your code, and develop those Linux/BSD/Fabrice skills. You might not be able to accomplish as much as these people did, but that's OK as well. The world still needs simpler programs.
kstrauser 4 days ago
rbanffy 3 days ago
cowlevel 4 days ago
chuckadams 4 days ago
I still want C to burn in a fire, but I suppose it's at least earned an honorable Viking funeral (yeah I know that's ahistorical but you get the idea).
echelon 4 days ago
That is the fault of the language.
KingOfCoders 4 days ago
Ah the old, you're using the tool wrong.
Yes, perhaps, although a tool that no one seems to be able to use correctly, see kernel bugs, zero days everywhere, bugs in cURL by people who seem very rigorous and thorough, in google and microsoft products, etc. I'm not sure the tool is innocent in this. If the highest paid C developers in the world can't use it, who can?
UncleMeat 4 days ago
edh649 4 days ago
geerlingguy 4 days ago
pizzafeelsright 4 days ago
himinlomax 4 days ago
jeffbee 4 days ago
chimeracoder 4 days ago
azizk121 4 days ago
WJW 4 days ago
> 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?
not_a9 4 days ago
cowlevel 4 days ago
Generally the attacker has to cause a sequence of heap allocations so that a certain kind of object gets allocated into the freed space that's still being pointed to, then use the old pointer to corrupt that object, then use the object. A good target is any C++ object with a vtable pointer - not sure if PHP is written in C++. If you can rewrite a vtable pointer and make it point to attacker-controlled data, you can get execution to jump to an attacker-controlled address.
jongjong 4 days ago
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.
wat10000 4 days ago
nijave 4 days ago
pettijohn 4 days ago
Maxious 4 days ago
rs999gti 4 days ago
dd8601fn 4 days ago
But also I haven’t seen much of that style of bulletin boards in ages. Maybe the occasional EEVBlog or Ars kinda count?
bombcar 4 days ago
rkozik1989 4 days ago
timw4mail 4 days ago
doublerabbit 4 days ago
robotmay 4 days ago
I do want to add some stupid forum features I remember from the 2000s. An RPG mod is definitely on my mind.
whycome 4 days ago
phplovesong 4 days ago
nijave 4 days ago
I guess node has taken some market share it seems like
cowlevel 4 days ago
dvdkon 4 days ago
whycome 4 days ago
And there are at least 3 other hugely popular php based forums that I occasionally check — and those are just for my own niche interests.
cowlevel 2 days ago
phplovesong 3 days ago
With AI, there is little need for PHP in 2026, even for the novice dev. The onl thing PHP had in the early 2000s was the FTP deployment story, but that has long faded. I van deploy a go binary WAY easier than a PHP application.
nostrademons 4 days ago
sgarland 4 days ago
phplovesong 3 days ago
nijave 4 days ago
apocalyptic0n3 4 days ago
StilesCrisis 4 days ago
SyneRyder 4 days ago
"Earlier this year, we worked with Alpha-Omega to scan PHP with Anthropic's Claude Mythos. But since the Mythos scan, we have added other tools, including OpenAI's Daybreak Red for validating reports and exploits, alongside sanitizer builds and reproduction environments that match our CI on every platform PHP supports."
https://thephp.foundation/blog/2026/10/21/todays-php-securit...
To me, this is either a black eye for the myth of Mythos, or worse - Mythos deliberately wouldn't reveal this vulnerability to them, even in a Glasswing style approval environment. It might not be the model's own fault, maybe the model was trained by Anthropic not to reveal certain vulnerabilities.
I think Claudes are great, Opus 5.5 has been incredibly helpful at building software and helping in other ways... but I am repeatedly seeing unhelpfulness (more like dismissiveness) from Anthropic models when it comes to cybersecurity defence, and even just secure bugfixes. At least, that's my personal take, on a very grumpy day with very little sleep.
tchalla 4 days ago
evandena 4 days ago
krelian 4 days ago
I know they waited two months with this but wouldn't it be wiser to wait just a little bit more than a few minutes after the fix released?
NoahZuniga 4 days ago
trollbridge 4 days ago
warkdarrior 4 days ago
krelian 4 days ago
eagleal 4 days ago
These articles were supposed to come out in about a week
wildmXranat 4 days ago
croes 4 days ago
chasil 4 days ago
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?
bananamogul 4 days ago
https://access.redhat.com/security/cve/cve-2026-109618 https://access.redhat.com/security/cve/cve-2026-109619
Is this because RedHat's default configuration isn't as vulnerable?
I'm ignorant of how these numbers are calculated. Could PHP on Debian, Ubuntu, etc. be a 9.2 but on RedHat it's only an 8.1 because RedHat has various mitigations?
chasil 4 days ago
The lower criticality may be wishful thinking.
jacobalcock 4 days ago
ang_cire 4 days ago
Well, that's my depressing statistic for the day...
sunaookami 4 days ago
ang_cire 4 days ago
pjmlp 4 days ago
pjmlp 4 days ago
binlog 4 days ago
pjmlp 4 days ago
And it isn't the only subset of Java around, see the embedded market with their own flavours as well.
https://developer.android.com/build/jdks
https://developer.android.com/about/versions/14/features#cor...
robotnikman 4 days ago
abirch 4 days ago
bananamogul 4 days ago
bguebert 4 days ago
https://w3techs.com/technologies/overview/programming_langua...
https://w3techs.com/technologies/overview/content_management
basilikum 4 days ago
binlog 4 days ago
driverdan 4 days ago
Gigachad 4 days ago
iAMkenough 4 days ago
Should we all go back to using Microsoft IIS to host web servers?
Gigachad 4 days ago
driverdan 4 days ago
asbv-1qq 4 days ago
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.
pixl97 4 days ago
So yea, it's a big deal.
SoftTalker 4 days ago
pixl97 4 days ago
shoobe < doobe
PHP was a component in the LAMP stack which was known to be 'free' and easy to setup for new users at the time as you say. That builds an ecosystem. Ecosystems are very hard to move away from, especially when your users are not highly technical. Security is almost always a second or third rate consideration for this type of user.
If you look at most applications configured in the enterprise, or practically any Microsoft web based application, they are not strongly security configured against write access to the machine.
trollbridge 4 days ago
It's a strategy that has so far paid off quite well. Thankfully in the era of AI it is gettig quite easy to refactor PHP into something else.
zelphirkalt 4 days ago
It just has so many flaws, that it will always be shitty in some way or another. For an actual business of say > 5 people, it will be worth using other technology to make their web presence.
There will always be something some of the following:
(1) You have 20 plugins to manage and update things often, and still have vulnerabilities and exploits going on with your site.
(2) Your theme is shitty and not actually responsive, because it is built upon a trash pile of bad styling and badly thought out WP theme structure which relies on concatenation rather than composition of parts.
(3) The database is a mess, because you need to shoehorn things into WP's very limiting DB design of posts and pages being the primitives to think in terms of.
(4) The site is super sluggish. Then self-taught "WP specialist" comes and "saves the day" by installing yet another caching plugin, adding even more attack surface. And now your site relies on yet a badly written cache plugin.
(5) WP itself will break your code and also break your data protection, by having updates, that include third-party fonts to misuse fonts, to render unicode characters that you used as friggin icon characters from that third party font. (no joke, this happened)
So you really cannot win this battle and your site will simply not be a site, that I would consider actually professionally made. The whole WP ecosystem is too broken, to allow you to succeed. You would have to go against many of its common practices and if you do that, you don't actually benefit from that ecosystem and can simply use another language and another web framework, that doesn't suck so much for creating web platforms.
WP is for quick blogging. Don't use it for other stuff.
nope1000 4 days ago
ashfg1 4 days ago
bitwize 4 days ago
basilikum 3 days ago
pizzafeelsright 4 days ago
Looks good, validates, works, and then trust is assumed.
basilikum 4 days ago
pizzafeelsright 4 days ago
pizzafeelsright 4 days ago
Everything was sound and every test passed for years along with every security scan because intent was not validated.
I would expect an unending source of exploits in the future until AI rewrites everything.
zdragnar 4 days ago
AI reviewing the code does help, though.
zoeysmithe 4 days ago
I don't know why php is impossible to harden, but its a security minefield, and if there is an RCE then its trivial to attack because so many of these systems are public facing. I veto any php based applications just over this.
rbanffy 4 days ago
jewel 4 days ago
rbanffy 4 days ago
schleck8 4 days ago
sigmarule 4 days ago
zelphirkalt 4 days ago
mg794613 4 days ago
Especially after fumbling it like this.
"Buy our product, because we found a bug", yeah and you leaked it too.
sehw 4 days ago
dewey 4 days ago
dspillett 4 days ago
thway15269037 4 days ago
dwohnitmok 4 days ago
https://bugs.php.net/bug.php?id=78876 marks the OOM bug as closed and fixed in 2020.
It seems the AI exploration was able to find variants of those bugs that were not fixed rather than exactly those bugs themselves?
dspillett 4 days ago
amiga386 4 days ago
The fix at the time wasn't to do proper cleanup on eralloc() failure, it was merely to avoid filename length being cast to a negative number.
ascii0eks84 4 days ago
throwaway2037 3 days ago
1vuio0pswjnm7 4 days ago
1792524843 | Upcoming Critical PHP Security Release | https://www.php.net/archive/2026.php | https://news.ycombinator.com/item?id=50171528 | 8 comments
1792525762 | Apparent CVSS 10.0 RCE in PHP core [x] | https://twitter.com/cyb3rops/status/2112616479061667936 | https://news.ycombinator.com/item?id=50171694 | 0 comments
1792526855 | Upcoming Critical PHP Security Release Wednesday 21 oct 14:00 UTC | https://www.php.net/archive/2026.php | https://news.ycombinator.com/item?id=50171937 | 0 comments
1792527350 | Upcoming Critical PHP Security Release | https://news-web.php.net/php.announce/509 | https://news.ycombinator.com/item?id=50172041 | 0 comments
1792527832 | Upcoming Critical PHP Security Release | https://www.php.net/archive/2026.php | https://news.ycombinator.com/item?id=50172142 | 0 comments
1792528374 | Upcoming Critical PHP Security Release | https://www.php.net/archive/2026.php | https://news.ycombinator.com/item?id=50172253 | 0 comments
1792530087 | PHP RCE Zero-Days CVE-2026-109618, CVE-2026-109619 Leak Early | https://www.cyberkendra.com/2026/10/php-cve-2026-109618-cve-... | https://news.ycombinator.com/item?id=50172614 | 0 comments
1792531634 | Pure PHP WebRTC+RTMP powering a Telegram webradio | https://twitter.com/DaniilGentili/status/2112635967597150323 | https://news.ycombinator.com/item?id=50172923 | 0 comments
1792533451 | Critical Vulnerabilities in PHP | https://cert.europa.eu/publications/security-advisories/2026... | https://news.ycombinator.com/item?id=50173247 | 1 comment
1792534818 | EU issues RED alert for the critical PHP vulnerability | https://cert.europa.eu/publications/security-advisories/2026... | https://news.ycombinator.com/item?id=50173483 | 0 comments
1792535009 | PHP warns admins of two critical flaws, emergency patches coming tomorrow | https://www.bleepingcomputer.com/news/security/php-warns-adm... | https://news.ycombinator.com/item?id=50173508 | 1 comment
1792536830 | Upcoming Critical PHP Security Release | https://www.php.net/archive/2026.php | https://news.ycombinator.com/item?id=50173797 | 0 comments
1792536907 | Upcoming Critical PHP Security Release | https://externals.io/message/132883 | https://news.ycombinator.com/item?id=50173817 | 0 comments
1792537022 | Upcoming Critical PHP Security Release | https://www.php.net/archive/2026.php | https://news.ycombinator.com/item?id=50173836 | 0 comments
1792539057 | Critical PHP Security Release | https://www.php.net/archive/2026.php | https://news.ycombinator.com/item?id=50174131 | 0 comments
1792539672 | Upcoming Critical PHP Security Release (CVSSv4 score of 9.2) | https://www.php.net/index.php | https://news.ycombinator.com/item?id=50174221 | 1 comment
1vuio0pswjnm7 4 days ago
1792585635 | Governments Take Websites Offline After PHP Security Warnings | https://www.bloomberg.com/news/articles/2026-10-21/governmen... | https://news.ycombinator.com/item?id=50179760 | 1 comment
1792585888 | Dutch National Cyber Security Center is Offline because it uses PHP | https://www.ncsc.nl/actueel | https://news.ycombinator.com/item?id=50179828 | 58 comments
1792586839 | Show HN: Passive exposure check for the PHP2Shell flaws (CVE-2026-109618/109619) | https://php2shell.xyz | https://news.ycombinator.com/item?id=50179999 | 0 comments
1792587855 | Show HN: Managed EmDash CMS hosting on Cloudflare, no PHP, no server | https://hostmyemdash.com/ | https://news.ycombinator.com/item?id=50180254 | 0 comments
1792589908 | Check/probe tool for PHP CVE-2026-109618/619 | https://php2shell.site/news.ycombinator.com/11c22360e8df83b4 | https://news.ycombinator.com/item?id=50180769 | 0 comments
1792589952 | PHP patches have been released | https://www.php.net/archive/2026.php | https://news.ycombinator.com/item?id=50180783 | 0 comments
1792590090 | Simple Proxy to secure your PHP from vulnerability CVE-2026-109618 | https://github.com/Qbix/proxy | https://news.ycombinator.com/item?id=50180810 | 0 comments
1792590108 | PHP Security advisory: Critical remote code execution vulnerabilities | https://www.php.net/archive/2026.php | https://news.ycombinator.com/item?id=50180818 | 0 comments
NooneAtAll3 4 days ago
simonw 4 days ago
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?
projektfu 4 days ago
bombcar 4 days ago
mjr00 4 days ago
Yes. I was at AWS when Spectre and Meltdown were discovered, and we received approximately a month of advance notice and put together teams to apply mitigations. The work of the team was on a need-to-know basis--even team members' managers only knew they were pulled onto a critical project, not what the specific project was. But there were still 30+ people in the company who knew, and that was just one company (I'm guessing Google/Azure/other cloud providers got similar advance notice).
Now, this is a much wider scale vulnerability, in the sense that Spectre/Meltdown primarily impacted cloud providers, but this attack impacts literally anyone who runs PHP. Dozens, if not hundreds, of companies likely got advance notice that a patch needed to be installed. In those companies there are teams of people applying those patches. All it takes is one of them who wants 15 minutes of internet fame to leak the details.
geerlingguy 4 days ago
The wider the pre-release news spreads, the more chance you get someone who will spill the beans (intentionally or not).
its606 4 days ago
Good4boothee 4 days ago
If I understand correctly someone showed off a video of exploit in action - just like the ones included in article - and the visible messages were enough for other LLM users to discover the exploited bug.
simonw 4 days ago
Were they already looped in or was it circulating outside of the trusted group already?
olafmol 4 days ago
yreg 4 days ago
They comment on it here: https://news.ycombinator.com/item?id=50176735
cpncrunch 4 days ago
So, if that is correct then the problem was the 24h prior notice about the patches, which gave time for people to use AI to find the bugs.
jwilk 4 days ago
I'm confused. How do you know it leaked?
simonw 4 days ago
> On Tuesday, October 20th, at around 15:00 UTC, the two CVE IDs began circulating on online forums and social media. They came with a wrong release time and a wrong CVSS score of 10.0 (the actual score is 9.2). No technical details leaked [...]
> As a result of the leak and pre-announcement around 20:00 UTC, Calif, one of the security firms that had reported the issues mistakenly published a video. It showed their proof of concept working against a number of targets and revealed a few additional, though limited, details about the vulnerabilities. Copies of the deleted video started circulating on social media soon after.
wren6991 4 days ago
iaaan 4 days ago
azyc 4 days ago
Would a low pm.max_requests narrow that part until people can patch? It obviously wouldn't help with the OPcache type confusion, since OPcache is shared memory across workers. airtnp also points out the old-branch backport just disables session upload progress, so session.upload_progress.enabled=0 looks like the cheaper interim knob.