Not a silly question at all. The PHP Foundation page mentions that they were given access to Mythos via a third company, and Anthropic paid for the security audit... and it didn't find this. It somehow took 5.6 Sol, and researchers who knew how to steer Sol.
"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."
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.
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.
> 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.
Apparently one of the distributors that had access to the patch broke the plan and went live with it earlier. So they had to rush patches and disclosures.
These articles were supposed to come out in about a week
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.
Personally, I am looking forward to any rich-enough companies, that make horrific WP websites and call it a day, rather than actually caring what they force upon people, to have their websites defaced. I have long held the opinion, that you can't really make an actually professional website, that is anything more than a blog, based on WP.
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.
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?
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.
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."
> 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.
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.
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???
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.
> 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.
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.
> How is a bug that was patched six years ago causing RCE today?
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.
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.
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.
We don't know yet. Not sure how that changes things either way. Impact goes far beyond getting exploited and the leak wasn't ideal in that regard either.
State hackers and others prepare how to use exploits long before they happen. If there was an opened known RCE in PHP they would have caused havoc immediately. Clearly that did not happen.
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/
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.
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.
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.
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.
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?
> 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.
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.
How reliably exploitable is it, if you know? EternalBlue was fairly close to a point-and-click exploit iirc, the early PoCs I’ve seen for this so far pin things for specific builds/images/configs, one consuming asan output, etc.
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.
Yes, but that doesn't solve all problems. You will still need to expose a CMS interface to the editorial team, be it command line, git based, or something else. A static site can't be attacked, but the system that manages the contents of the static website or its compilation can.
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 was superficial. It's also well-established that models can find novel vulns at this point.
My understanding at the time I wrote that was “someone else using chat-logged OAI model: September???; OAI using unspecified model: October???”, and when I say “Navier-Stokes-style-scoop” I am thinking along the same lines as the comment I made during that controversy, here: https://news.ycombinator.com/item?id=49639648. I don’t buy that their public statements are not “technically correct but misleading without internal context” on these matters.
> On August 11th researcher Ryan A at Calif reported an unconditional remote code execution with the same root cause as the OOM problem we had found in 2024. OpenAI independently reported the same root cause on the same day
> The PHP Foundation got the PHP project into the Patch the Planet program, as part of which security firm Calif began an audit of PHP on July 30th, 2026. On August 11th researcher Ryan A at Calif reported an unconditional remote code execution with the same root cause as the OOM problem we had found in 2024. OpenAI independently reported the same root cause on the same day
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.
Could that “single instance” be copied enough times in places also used in training, so represented much more in the training data than once? If it only takes a small number of malicious chunks of information can potentially poison an LLM or large size (ref: https://www.turing.ac.uk/blog/llms-may-be-more-vulnerable-da...), then presumably a small number of a good chunk can influence output similarly?
97 comments
[ 0.31 ms ] story [ 11.4 ms ] thread"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.
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.
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?
These articles were supposed to come out in about a week
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.
So yea, it's a big deal.
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.
Looks good, validates, works, and then trust is assumed.
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.
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.
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?
They comment on it here: https://news.ycombinator.com/item?id=50176735
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.
I'm confused. How do you know it leaked?
> 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.
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.
Is this HN or boomer FB? I don't know anymore.
Especially after fumbling it like this.
"Buy our product, because we found a bug", yeah and you leaked it too.
https://news.ycombinator.com/item?id=50188948
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.
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.
No, scratch that. I should replace it with something that is not a trash fire.
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.
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?
The lower criticality may be wishful thinking.
> 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.
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.
[1]https://www.scientificamerican.com/article/openais-blockbust...
What a coincidence.
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.