Potential third critical PHP CVE

Posted by mpaepper 17 hours ago

Comments

Comment by hannob 16 hours ago

From the little info one can see here, it looks like this is a PHP script causing a memory corruption. So you probably need to be able to run PHP code to exploit it.

That's... not a particularly unusual issue. PHP has a large codebase, releases with plenty of fixed crashes come out regularly. It becomes critical if there's a remote path to exploitation.

I see no indication that this is a "critical" PHP flaw. And the Reply from the person who found it seems to confirm that. ("I keep getting asked about mitigations, here's the mitigation: don't worry about it kitten")

Comment by hannob 2 hours ago

I cannot edit my comment, but it seems it's there's remote impact, so have to correct myself: https://mastodon.social/@hanno/117484049093015780

Comment by akersten 14 hours ago

I read their quip about mitigation as more of a defeatist "this is fine" meme than actual advice that it's a nothingburger, but I'm pretty cynical on PHP as a whole. We'll have to wait and see if today's a hat trick day or just a double header.

Comment by selckin 16 hours ago

https://www.openwall.com/lists/oss-security/2026/10/21/23

Comment by nr378 15 hours ago

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.

Comment by athrowaway3z 15 hours ago

Stop posting this theory because it's obviously wrong. From the thread:

> Elise: confirmed working on 8.5.10 too

Comment by nr378 15 hours ago

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.

Comment by athrowaway3z 14 hours ago

Its nothing

https://www.reddit.com/r/PHP/comments/1xbyxd2/new_php_cve_di...

Comment by akersten 14 hours ago

Color me unconvinced that the dev team that sat on the 2024 security audit leading to today's CVE successfully explored the ramifications of a new memory bug in an hour

Comment by bawolff 15 hours ago

There is literally no info on how this is triggered. From the info this could range anywhere from total non issue to zOMG. Given how keyed up everyone is, i lean towards the former.

honestly, i would just wait for php announcement and assume its no big deal until then.

Comment by yjftsjthsd-h 16 hours ago

Oh, it's going to be one of those weeks.

Comment by athrowaway3z 15 hours ago

I've spent some deepseek tokens on trying to reproduce this CVE with what is known so far; (Very little beyond effected versions and a hint that her search started because of the current bug, but that it's probably a different one entirely).

It found nothing.

Take that for what it is.

Together with https://www.openwall.com/lists/oss-security/2026/10/21/23 you're probably not going to need to stay up for this.

Comment by 14 hours ago

Comment by mvac 16 hours ago

PHP is having a really bad day today

Comment by ChrisArchitect 15 hours ago

Source thread: https://fedi.katze.sh/@elise/117479383739450605 (https://news.ycombinator.com/item?id=50182930)

Comment by tiku 16 hours ago

Got really triggered... By the font.

Comment by 15 hours ago

Comment by senior_hellowor 17 hours ago

[dead]

Comment by rvz 15 hours ago

I mean it the first time [0], PHP is done.

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

Comment by chinathrow 15 hours ago

It's absolutely not.