There are two CVE's (CVE-2026-109618, CVE-2026-109619), both with a rating of 9.2 out of 10. They allow unauthenticated code execution.

From the phpfoundation website:

CVE-2026-109618 / GHSA-w8hw-w9fx-j79w: RCE via OOM corruption (out-of-memory): If a request reached PHP's memory_limit at exactly the wrong moment, PHP could leave partially initialized internal data behind and later treat it as valid, corrupting memory. On Apache with mod_php, an unauthenticated request can trigger this before any application code runs, and full remote code execution was demonstrated with default settings. Remote code execution was also confirmed on PHP-FPM through application-level code paths.

CVE-2026-109619 / GHSA-6wmf-4rv5-p3rp: RCE via stale global state: A fatal error at the wrong point could leave internal state pointing to memory that belonged to a previous request. A later request handled by the same worker could then use that freed memory. A use-after-free and worker crash were confirmed, and the reporter demonstrated remote code execution against a real-world application running on Apache with mod_php.

What confuses me as someone who hasn't written PHP in ages, is why is it supposedly so easy for a request to hit the memory limit? Does this only work on servers that accept user uploads and other large request payloads? People are saying a static PHP page can be exploited, but I don't understand how if it's behind even a basic nginx instance with default request limit of 1MB.

I remember someone on hacker news saying they were able to dump the whole database from their server, I cannot know if that s true but I don't think everybody panicked for nothing

Yes the vulns are real. No that does not mean a system with the vuln is automatically and noticeably exploitable: that assumes there are no other defense systems or simply other happenstance logical walls around (firewalls, datacenter range blocks, seven proxies, 28 NATs, Anubis, whathaveyou).

My understanding is that CVEs are ranked not by Real World conditions but rather under an "idealized threat condition" that imagines your machine is essentially connected with a straight wire to the root DNS serves of the internet, given a public IPv4 address, and the off switch is dislodged or somehow made unavailable.

From the very little I've researched, a DoS with it isn't hard but for RCE one needs to know some pointers inside... doable if you assume it's Debian or something then just download a bunch of versions locally and try them. This also implies that most hardened distributions are all unaffected (because relocations) and source builds are effectively unaffected unless the binary is dumped somehow.

Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:

5 acronyms in this thread; the most compressed thread commented on today has 9 acronyms.

[Thread #145 for this comm, first seen 22nd Oct 2026, 21:30] [FAQ] [Full list] [Contact] [Source code]

The PHP vulnerabilities (yes there is more than one) are relatively easy to exploit if you can fiddle with what requests your server receives (easy).

The DNS exploit requires someone to figure out how to man-in-the-middle your connection. While that is trivial for governments, it is much less likely to be done by purely bad actors, simply for how hard "internet" integration is and how visible the problem ends up.

Both are big problems, but only one of them is continually exploitable, as the DNS issues have been largely resolved even before the very public disclosure.