nr378

Whether it's exactly the same issue or not, the point remains: a double-free in and of itself doesn't establish a critical CVE (or even a high one). There's a known double-free in that GitHub issue, if there's a second independent one, it shouldn't necessarily cause any more concern than the first one.

That post appears to show the same stack trace as this reported issue https://github.com/php/php-src/issues/24488, which is a confirmed GC regression in 8.5.12 but it is not exploitable (the allocator's shadow protection kills it), and it does not result in RCE and is not a critical CVE.

It's a very different shape to the other two CVEs, and a use-after-free doesn't necessarily immediately imply a critical CVE.

That partial stack trace linked above seems to match this GitHub issue, which has much more information: https://github.com/php/php-src/issues/24488 (double-free introduced in 8.5.12)

From what I can see, this causes a crash only, and isn't weaponisable. It's a use-after-free, but the reclaim window is zero by construction.

It seems like OpenAI are trying to frame this as if AI did all the work here, but it's not really true given what Calif say (https://calif.io/php2shell/):

> How did we find this?

> No special harness, or access to models that weren't generally available to everyone were used in the initial bug discovery. I focused on something I had a background in, knew its vulnerability history well, and held a theory that specific bugs lurk within the codebase. This shows that "know your target" is still as applicable as ever, even in the LLM dominated VR age. No model is simply capable of unearthing "all bugs" with simple prompts. At least for now.

> There are some practical research implications here. LLMs may have ingested public historical vuln data, but in their default variant analysis tends to move from the newest and most prominent bugs toward nearby older code. They do not reliably begin with obscure twenty-year-old exploitation primitives. Keeping your own mental catalog of a target's vulnerability history lets you prompt that direction explicitly.

Looks like a co-ordinated disclosure between Wiz, Calif and OpenAI:

https://www.php2shell.com/

https://www.wiz.io/blog/php2shell-php-rce

https://calif.io/php2shell/

https://openai.com/index/coordinated-disclosure-of-critical-... (not yet live)

https://thephp.foundation/blog/2026/10/21/todays-php-securit... (not yet live)

Fixed versions have been released slightly early, along with full technical details:

https://www.php.net/archive/2026.php#2026-10-21-5

RCE via OOM corruption - https://github.com/php/php-src/security/advisories/GHSA-w8hw...

RCE via stale global state - https://github.com/php/php-src/security/advisories/GHSA-6wmf...

PHP is definitely more at risk of this class of vulnerability because fatal errors are longjmps which skip resource clean-ups. In a runtime with real unwinding, this exploit class can't exist.

I've tested the CVEs on PHP 8.5.11 and `session.upload_progress.enabled = Off` definitely increases safety but it doesn't guarantee it. Use of plugins can open up additional exposure.

Agree, I think switching off any running PHP services *at the power socket* is a pretty rational response at this point.

Given that this affects every PHP version from the past decade, and that the exploit instructions are circulating at the top of twitter, and that there's no fix available yet, it doesn't seem outrageous to assume every major PHP website is already compromised?

The upgrade instructions here should include torching your hosts and starting again.

I think OpenWrt is the more significant project nowadays, and routers with OpenWrt pre-installed are already available

This is a supply constraint and requires no assumption about demand - HBM packaging capacity constrains the amount of wafers that can go towards HBM (regardless of price in the near term), and excess wafer capacity will be dumped into DDR5 and crash DDR5 margins.

Regardless of AI demand: as it currently stands, it seems that DDR5 prices will drop substantially in ~24 months as additional wafer capacity comes online between SK Hynix's fabs M15X and Yongin Fab 1, Samsung's fabs Pyeongtaek P4 and P5 Fab 1, and Micron's fabs Boise ID1 and Tongluo (+ whatever CXMT do as well), and HBM production hits HBM packaging bottlenecks (HBM wafer capacity exceeds HBM packaging capacity) which means the wafer capacity will start getting dumped into DDR5 instead (unless the HBM packaging bottleneck is solved in the next 24 months).

Yep they're definitely getting ready to yank using your subscription with the agent SDK - this page has just been pulled: https://support.claude.com/en/articles/15036540-use-the-clau...

That's not a good sign for Conductor...

This seems like more co-ordinated propaganda to try to help OpenAI and Anthropic create a cartel and win their anti-trust waiver.

The key sentence beneath the headline: "OpenAI said all of the government data accessed by bots was public."

[1] https://www.telegraph.co.uk/business/2026/09/26/open-ai-gove...

[2] https://www.nytimes.com/2026/09/25/technology/openais-ai-us-...

[3] https://www.bbc.co.uk/news/articles/cw62jje658dlo

Yep, I'm personally finding Opus 5.5 to be the first real leap I've felt since Opus 4.5. The time-to-first-token seems dramatically better in Claude Code compared to Fable 5.1/Opus 5 as well, which really helps both interactivity and also overall time-to-completion.

It also burns Claude subscription quota much more slowly than Fable, which is nice.

This is great news - the Snapdragon X2 Elite Extreme X2E-96-100 isn't too far off the Apple M5 Pro.

[1] https://browser.geekbench.com/processors/snapdragon-x2-elite...

[2] https://browser.geekbench.com/macs/macbook-pro-14-inch-2026-...

When I used to work on projects involving classified information, I worked on an air-gapped network. Not "air-gapped, except for third-party public internet package managers", completely and physically air-gapped from the public internet. That was a basic security practice and completely non-negotiable (and really inconvenient!).

If I were hypothetically running a frontier lab, and I was hypothetically running capture the flag evaluations with my latest and smartest models, where I intentionally instruct them to develop vulnerabilities and exploit infrastructure without safeguards, I would also use an air-gapped network, and not trust that independent third party services were perfectly secure and could never be used as a proxy (particularly Java-based ones, in light of the log4j incident).

To me this is pretty basic stuff, the fact trillion dollar labs don't do it properly is... bemusing.

To be clear, I'm not saying that a model hacking a company isn't bad, but I am cynically asserting that interested parties are misrepresenting and exaggerating events for their own benefit.

The description reads "the elite task of discovering 14 Hugging Face API tokens that careless developers had committed to public GitHub repositories, and used them to try to get benchmark solutions from directly from Hugging Face by applying a template injection flaw that’s been known about since 2015[1]."

Chaining a public token to an 11-year-old Jinja2 template injection vuln shouldn't be dressed up as an unprecedented "alien intellect" that threatens human civilisation. (And HuggingFace should take some flack for having such a dated vulnerability exposed - if your Bank was compromised in this way, you'd be blaming your bank, not the attacker.)

One correction is fair though, the 14 tokens were in a public Hugging Face dataset not a public GitHub repository. I've updated the post to reflect that.

[1] https://blackhat.com/docs/us-15/materials/us-15-Kettle-Serve...

Please see below, one detail was incorrect and has been acknowledged and amended.

Thank you, you're correct. Effort.news was one of my research sources, but you're right that although OpenAI use Irregular, they were not involved in the specific HF incident (although the failure mode was otherwise identical). I've updated the post to make that clear.

Qualcomm have an architecture license and the Snapdragon X2 Elite Extreme X2E-96-100 isn't too far off the M5 Pro.

[1] https://browser.geekbench.com/processors/snapdragon-x2-elite...

[2] https://browser.geekbench.com/macs/macbook-pro-14-inch-2026-...