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.
I don't think the timelines make sense for it to have been included in training data, LLM training does not seem to be nearly efficient enough to learn these things from lone examples, and it wouldn't make sense for this earlier work to have made its way into both OpenAI and Gemini's data. Navier-Stokes is not strong evidence that this kind of thing can happen, as OpenAI denies that Buckmaster's work was in the training data for the model they used, Buckmaster didn't have a blowup that they could steal, and Scientific American reports[1] that the similarities between their approaches were superficial. It's also well-established that models can find novel vulns at this point.
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.
Many exploits are used by security services, so this gives time to wrap any investigations or surveillance or find another method of accessing target servers.
Can anyone explain the lack of the irresponsible disclosure in the 'Responsible' disclosure timeline? The one that happened just before the coordinated release?
People should stop reading AI slop on X and other social media. The exploit is advanced and took some effort to fix. If there really was an open RCE in PHP for anyone to use the impact would be massive.
C is not to blame for programmers using its features unwisely and, as a result, writing buggy code. Writing secure C code requires discipline, and, most likely, keeping yourself limited to a subset of the language.
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.
> C is not to blame for programmers using its features unwisely and, as a result, writing buggy code. Writing secure C code requires discipline, and, most likely, keeping yourself limited to a subset of the language.
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.
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.
Yes and no. I'd say there's nothing wrong with C - it's not evil - but maybe we still shouldn't use it because we should demand things C doesn't provide. There's nothing wrong with assembly code either but we rarely use it.
I didn't say "make no mistakes". I said "using its features unwisely". If you can't write software that manages shared mutable state, then don't do it. The world still needs lots of simpler programs.
Don't you think the style of video looks a bit unprofessional? It's like the next iPhone being presented by the Apple CEO but using a vTuber avatar with subway surfer gameplay in the background.
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."
Which makes someone to think, whether Calif could not wait for the responsible disclosure. Or someone leaked the video for someone they should not have.
> 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?
It's generally safe for a defender to assume that if an attacker can corrupt the heap they can achieve RCE, because there are usually so many ways to do it. They're all very specific ways that are hard to find because of all the complexity and mitigations, but there are a practically unlimited supply if someone puts in the effort to find one. But as a defender you don't need to, you should just say game over as soon as you get heap corruption, and go fix it.
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.
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/
One pattern of AI-assisted writing I hate is that technical articles now read as Atlantic journalistic tech-noir stories, which require scrolling through 20+ pages of content to get to the meat of a post.
This is a very misleading stat. A single path or subdomain on the website needs to be running PHP for the entire site to count as “powered by PHP”. Plus it excludes sites whose server-side tech cannot be identified at all (aka properly configured ones).
Actually even more nowadays, given Android with 75% market share, even if it is a different brand of coffee, alongside all developers using JetBrains products even when not using Java as their programming language.
Depends on how you define Java. Android can execute Java programs, and bundles a handful of OpenJDK libraries, but it stopped running the JVM a long time ago.
It’s still popular af. Almost half of any cms site online is powered by Wordpress. Many sales sites use woocommerce (Wordpress plugin). Message boards for sure (phpbb!). Moodle and other similar learning management tools run on PHP. Other cms systems like drupal and joomla make up another big portion of cms installs. I think the custom Wikipedia (mediawiki?) is php.
PHP is ONLY popular because of mainly wordpress. Usage outside the big CMS are minimal at best, in 2026. I dont see much greenfield / PHP jobs that are not legacy software these days.
No way. Forums are still incredibly popular. Something like RedFlagDeals has an entire business based around their forum and get close to 40m page views per month and more than 3m uniques.
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.
I slopcoded my own forum software in Elixir/Phoenix recently, starting from my memories of phpBB and SMF forums I used to run. I’m using it as a forum for my vintage camera stall as I have a lot of people who enjoy hanging out at the stall, and it turns out they enjoy hanging out on a retro forum too.
I do want to add some stupid forum features I remember from the 2000s. An RPG mod is definitely on my mind.
phpBB, vbulletin, and XenForo still power more than you might realize - often websites that still have comments are using one of those as a back-end, even if you can't access it directly.
> 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.
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.
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?
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?
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.
I like to be AI sceptical as well but I think it's even more noticeable if the flaw is in 20 year old code which thousands of people have read and reviewed and not noticed, isn't it?
I discovered a large security concern that has existed for a decade, since the code was originally written. I was working on an unrelated task when my AI agent discovered an oversight because the agent happen to examine that file.
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.
Eh, it's an RCE that's been around forever and runs on a pretty large number of websites. Worse a lot of businesses have things like wordpress sites so one of those getting compromised is a foot in the door allowing movement into the more protected areas of the network.
Web servers should not be a foot in the door. They should be assumed hostile and stringently limited. PHP especially has been notorious for remotely exploitable bugs but that's probably more due to its popularity and wide use by beginners than it being strictly worse than any other stack in this regard.
I treat my PHP servers like they're a hostile entity, going so far as to put them on their own VLANs, turning off optimisations for virtualisations to avoid container escaping, and so forth.
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.
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.
php RCE's are a big deal. So much of public facing stuff is drupal or wordpress and heaven knows all the places php is being used. Think embedded systems and appliances and in turn-key software.
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.
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.
That's why so much emphasis is now placed on trying to make incorrect software either fail to build or fail at runtime in a way that doesn't let people take over the computer. C makes it extremely likely that a random correctness issue will be a security issue. Newer languages much less so. They're far from perfect but it's a lot better.
Grinding through abandoned source code in hopes of finding a vulnerability isn't exactly the most fulfilling work for many, perfect use case for AI which doesn't sleep.
Apparently both bugs had been reported previously, pre-AI, if so some important questions need to be asked about how those reports slipped through without a fix.
That report describes sending a 2^31 length filename, which is cast to a negative number, which leads to asking erealloc() to allocate a very large buffer, which fails, which leads to the symptoms of the bug we're discussing today (mid-request allocation failure becomes a partially initialised request)
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.
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.
> I want to understand how it leaked. I guess a whole lot of people were looped in between September 21 and October 21?
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.
Even some smaller vulnerabilities are spread through hosting companies pretty quickly within a day or two prior to public release, to give teams time to make sure staff will be ready to patch immediately.
The wider the pre-release news spreads, the more chance you get someone who will spill the beans (intentionally or not).
Two months is way too long for this, and the people involved seem to not know the "way" to do this - it shouldn't have taken a month from "reports" to "PHP acknowledges" which smells like "we sent an email or filled out a web form" when the ACTUAL reporting mechanism is "we talked to our friends at <MAJOR DISTRO> or <WORDPRESS> who called the right people and a patch is being slipped in."
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.
From what I gather, https://x.com/J4ck3LSyN/status/2112703096443097263 figured it out after the disclosure by wiz.io and openai (which I think was 24h before the patch landed). So they then used AI models to analyze the php code and independently found the vulnerabilities.
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.
that's the million-dollar question currently. The guy posting the movie on X is referring back to Calif.io and other person as the creators of the video. Also, it's not a working exploit, but a video of a PoC, including a dancing manga character, so I'm wondering why a company like Calif.io creates such a thing. Another "interesting" development: chainguard unilaterally decided to break embargo 6 hours before the official publishing, by releasing patched container images. Why???
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.
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...
[1]https://www.scientificamerican.com/article/openais-blockbust...
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
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.
https://github.com/php/php-src/commit/712e60f9edfd03f0960fc4...
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.
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.
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.
"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.
After all, furries run the internet.
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."
sounds like a good time
> 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?
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.
Well, that's my depressing statistic for the day...
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...
I guess node has taken some market share it seems like
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.
But also I haven’t seen much of that style of bulletin boards in ages. Maybe the occasional EEVBlog or Ars kinda count?
I do want to add some stupid forum features I remember from the 2000s. An RPG mod is definitely on my mind.
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?
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?
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?
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.
Looks good, validates, works, and then trust is assumed.
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.
AI reviewing the code does help, though.
So yea, it's a big deal.
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.
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.
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.
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.
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?
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.
No, scratch that. I should replace it with something that is not a trash fire.
Especially after fumbling it like this.
"Buy our product, because we found a bug", yeah and you leaked it too.
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?
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.
The wider the pre-release news spreads, the more chance you get someone who will spill the beans (intentionally or not).
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.
Were they already looped in or was it circulating outside of the trusted group already?
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.
They comment on it here: https://news.ycombinator.com/item?id=50176735
I'm confused. How do you know it leaked?