Potential third critical PHP CVE

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.

▲

athrowaway3z 2 hours ago | parent [-]

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

> Elise: confirmed working on 8.5.10 too

▲

nr378 2 hours ago | parent [-]

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.

▲

athrowaway3z an hour ago | parent [-]

Its nothing

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

	▲	akersten an hour ago \| parent [-]
		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

▲

hannob 2 hours ago | parent | prev | next [-]

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")

	▲	akersten an hour ago \| parent [-]
		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.

▲

selckin 2 hours ago | parent | prev | next [-]

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

▲

athrowaway3z 2 hours ago | parent | prev | next [-]

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.

▲

bawolff 2 hours ago | parent | prev | next [-]

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.

▲

yjftsjthsd-h 2 hours ago | parent | prev | next [-]

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

▲

ChrisArchitect 2 hours ago | parent | prev | next [-]

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

▲

mvac 3 hours ago | parent | prev | next [-]

PHP is having a really bad day today

▲

tiku 3 hours ago | parent | prev | next [-]

Got really triggered... By the font.

▲

rvz 2 hours ago | parent | prev [-]

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

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

	▲	chinathrow 2 hours ago \| parent [-]
		It's absolutely not.