PHP core memory flaws (CVE-2026-109618/109619): when OOM handling corrupts the request

What happened

On 21 October 2026, the PHP project published fixes for CVE-2026-109618 and CVE-2026-109619, two memory-safety issues in the interpreter itself. The first: PHP uses longjmp() to bail out of the current context on out-of-memory errors, and some code paths leave request memory uninitialized before the next allocation — the request cleanup procedure then operates on that memory. The second: global state that temporarily points into request memory is not always corrected, so a later request can act on stale pointers.

Both are the kind of flaw that turns a memory-pressure event — a big import, a pathological regex, a burst of image resizes — into memory corruption inside the PHP worker.

Impact

Memory corruption in a shared PHP-FPM worker can crash the pool (denial of service) and, in the worst case, be shaped into information disclosure or code execution. For Magento stores, the workers serve checkout: a crash loop during a sale is lost revenue, and a corrupted worker handling payment callbacks is a data-integrity nightmare.

Root cause in one paragraph

The OOM escape hatch (longjmp) skips the normal cleanup ordering, so invariants the rest of the engine assumes — initialized memory, valid global pointers — silently stop holding; the code that runs afterward was written against guarantees the jump had just voided.

What to do now

• Upgrade PHP to the fixed releases on every host (FPM pools, cron workers, queue consumers, CLI import boxes) — not just the web tier.
• Watch PHP release announcements as a standing feed; interpreter flaws affect all frameworks at once.
• Cap worker memory (memory_limit) sanely and monitor OOM kills — frequent OOMs are both the trigger and a signal.
• Restart FPM pools after upgrading; a reload keeps old workers on the vulnerable binary.
• Load-test imports and image pipelines after the upgrade to confirm behavior is unchanged.

What this means for Magento stores

Magento runs on PHP, so a PHP-interpreter flaw is a Magento flaw with extra steps. Your patching checklist already covers composer update for the app — extend the same discipline to the runtime: pin PHP minor versions in your Docker images and govard blueprints, rebuild on security releases, and roll forward. The stores that patch PHP within days are the ones that never learn whether the exploit was practical.

Sources

• NVD: CVE-2026-109618, CVE-2026-109619
• PHP project security announcements, October 2026

Next in this series: Duplicator PHP Object Injection (CVE-2026-82814) — /blog/cve-2026-duplicator-82814