Both defects are in code that runs for ordinary web requests. That is why the blast radius is wide, and why the patches had to avoid breaking extensions. The PHP Foundation’s 21 October 2026 note describes the fixes as difficult for that reason. This page stays with what the security advisories themselves establish.
CVE-2026-109618, in defender language
Out-of-memory handling used to leave the current request by longjmp(). If that jump happens while request memory is only partly set up, shutdown later treats the incomplete memory as real. mod_php always reaches shutdown, including when startup failed, so the bug can be hit before the application runs. FPM throws away the child on startup failure, which removes that particular path, and remains exposed once a request has started and then runs out of memory.
The advisory also explains why a request can exhaust memory while still looking like it fits in post_max_size: multipart bodies without a usable content length, part headers that expand when PHP stores them, and empty file fields that still allocate metadata. Those are reasons to enforce size and complexity at the frontend. They are not a recipe, and they are not a substitute for the patch that removes the longjmp path.
CVE-2026-109619, in defender language
The worker is long-lived. Request memory is not. Anything in a process-global field has to be cleared before that memory is freed, and it has to stay clear until the next request finishes initialization. Fatal errors and some shutdown diagnostics break that pairing. The next request’s early INI handling or session upload progress can then use the stale pointer.
The producer and the consumer are different HTTP requests on the same worker. More workers lower the chance that both requests meet, and they do not remove the bug. Recycling workers with pm.max_requests shortens the lifetime of any leftover state and does not reset the bug inside a single request pair.
What the patch changes, operationally
After the update you should see the same application behavior, a new binary or package revision, and workers that have actually restarted. You should not need to disable warnings to be safe. If an extension ABI no longer loads, that is a compatibility failure of the rollout, not evidence the CVE remains.
For the configuration that remains useful even on a patched build, PHP specifically suggests keeping session upload progress off when the application does not use it, and keeping request-size limits at the frontend.
Questions
Does this page include exploit steps?
No. It stays at the level of the public advisories so operators can choose a fix and a verification plan.