If you can corrupt memory in a controllable way, you can get a computer to do just about anything that process has rights to. Possibly even the kernel, if you can get at some shared memory.

But it's not a given that memory corruption is exploitable. I thought to call something an RCE you need a working exploit?

Isn't resource consumption a DoS?

A denial of service is a different class of vulnerability (a minor one, generally).

Presumably one of Anthropic, Google, or Apache possesses a working exploit, because the official Apache Foundation report on this CVE claims RCE is possible.

I was prepared to disagree with you, but I agree: I'd say there's a strong norm of not calling things RCE unless you can actually demonstrate RCE, or at least have a clean pathway to demonstrating it (e.g. a full write-what-where).

It's perfectly sufficient to have a CVE for just memory corruption, so the "RCE" framing here feels overstated. Particularly when an LLM should easily prove RCE out if it is in fact present.

Another comment says it has a CVSS score of 9.8 which means CVE, easy to exploit, and an exploit gives LOTS of access.

Before we get too whiny about "it's only memory corruption without any RCE PoC", let's wait until the CVE is unembargoed.

[delayed]

I don't know the backstory here, but there's a long and colorful history of vendors and other parties guessing that some contrived memory corruption bug isn't exploitable and then being proven wrong, so the industry now more or less defaults to the assumption that it's exploitable.

Let me remind you that in response to the PHP bug, one of the front-page HN posts was a guy saying it's probably not exploitable and another offering Bitcoin to anyone who pops their server... with predictable results.

People can be pretty creative with exploitation primitives, and LLMs now replicate that at a scale. And yep, if you found a use-after-free that can be triggered remotely in PHP under some reasonable assumptions, you should probably treat it as a security bug.