A web request is supposed to be a brief transaction: PHP receives it, runs the application, then clears away the request’s temporary state. But what if the cleanup begins before that state is fully built? Or if something meant to disappear survives into the next request? Those overlooked moments are at the heart of two critical vulnerabilities now fixed in PHP.

The flaws could allow unauthenticated remote code execution—the ability to make a server run an attacker’s code without first logging in. PHP’s security team says all PHP installations serving web requests are at risk, including PHP-FPM, Apache’s mod_php, php-cgi, FrankenPHP and LiteSpeed. The team considers mod_php the highest-risk setup, citing a demonstrated attack that can be triggered before application code runs.

When an emergency interrupts initialization

The first flaw, CVE-2026-109618, involves what happens when PHP runs out of memory. Programs need memory to hold information while they work. PHP also has a configured memory limit, so reaching that limit can trigger an error-handling path rather than simply allowing memory use to grow indefinitely.

The danger here is a badly timed interruption. If memory exhaustion occurs while PHP is still setting up internal data for a request, some of that data may be only partly initialized. During cleanup, PHP can then mistake the incomplete information for valid state. In plain terms, the routine meant to tidy up after a failure may itself handle the damaged situation incorrectly.

That makes the vulnerability more subtle than an attacker simply sending an unusually large request. It lies in the interaction between a resource limit, partially constructed internal data and code that tries to recover safely. The advisory warns that changing the PHP memory limit can reduce exposure to one route into the flaw, but cannot prevent every underlying allocation failure.

The next request may inherit a ghost

The second flaw, CVE-2026-109619, is about persistence rather than interruption. Some internal state belongs only to one request. If PHP frees the memory holding that state but a reference to it remains, a later request handled by the same worker may encounter a stale pointer—a reference to a place in memory that is no longer meant to contain that data.

This is why the boundary between requests matters. A server worker may handle many requests over its lifetime, even though each visitor’s request should be treated as a fresh job. If request-specific state leaks across that boundary and is used before normal initialization resets it, the next request can encounter something left over from the previous one. The advisory says the flaw can lead to remote code execution.

The two bugs expose different weaknesses in the same basic promise: that a request’s internal machinery will be valid while it is used, and gone when it is done. One concerns a failure during setup; the other concerns state that outlives its rightful moment. Neither requires an attacker to sign in, according to the advisory.

Updating is the real fix

PHP has released patched versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and urges users to update immediately. Linux distributions and long-term-support vendors received patches in advance, so administrators should check their vendor’s packages. PHP 8.1 and older no longer receive fixes from the PHP project, although some vendors may provide backported patches.

For systems that cannot be updated at once, the advisory describes temporary measures—not a guarantee of safety. For the memory-exhaustion flaw, administrators can remove PHP’s controllable memory limit and restrict request sizes and complexity at the server or proxy. For the stale-state flaw, disabling session upload progress before request parsing and restarting workers blocks confirmed attack paths, but not necessarily other variants.

That distinction is important: a workaround can narrow a doorway without repairing the building. PHP processes the ordinary traffic of countless websites, and small assumptions about memory, cleanup and worker reuse can become security boundaries. The safest response is to install a fixed release; the deeper lesson is that in long-running software, what happens between requests can matter as much as what happens inside one.