Two Critical PHP Vulnerabilities Can Lead to RCE: What We Know So Far

On October 21, 2026, the PHP Security Team published a security advisory for two critical vulnerabilities: CVE-2026-109618 and CVE-2026-109619.

Both can lead to unauthenticated remote code execution, meaning a remote client may be able to execute code without authenticating first.

This is not a Laravel, Symfony, or individual Composer-package vulnerability. The problem sits lower in the stack, inside the PHP runtime that handles web requests.

The PHP Security Team explicitly states that both vulnerabilities can allow remote code execution without authentication.

For a web runtime, this is one of the most dangerous classes of issue because the attack surface begins during HTTP-request handling and does not necessarily require application authentication.

The PHP team considers the risk highest for mod_php, where an exploit path has been demonstrated that can trigger before application code runs.

This matters for Laravel projects because a typical production stack often uses Nginx with PHP-FPM.

Having Nginx in front of PHP does not remove a runtime vulnerability. If a request reaches the PHP runtime, the vulnerable code path may still be relevant.

PHP may interrupt execution while internal request data is only partially initialized.

Cleanup logic may then treat invalid state as valid. That corruption creates a path toward RCE.

The second vulnerability involves internal state from one request that may survive after its backing memory is freed.

A later request on the same worker may use that stale state before normal initialization resets it.

The problem boundary therefore also crosses sequential requests handled by a long-lived worker.

Login, permissions, API tokens, and middleware operate at the application layer.

An unauthenticated runtime vulnerability may trigger during or before normal application processing. So "the route requires auth" and "the PHP runtime is not exposed" are not the same statement.

Composer manages application dependencies in vendor/. CVE-2026-109618 and CVE-2026-109619 are PHP runtime vulnerabilities.

An application can therefore have current packages and a clean dependency audit while still running on a vulnerable PHP build.

The PHP project released 8.2.35, 8.3.36, 8.4.27, and 8.5.12 with fixes for both vulnerabilities.

PHP 8.1 and older branches no longer receive normal security updates from the PHP project. Some Linux distributions and LTS vendors may provide backported fixes.

That means php -v alone may not always be enough for a distribution package because vendor security status can differ from upstream version numbering.

Production PHP-FPM, CLI for cron and queue workers, a development server, Docker workspace, CI image, and local interpreter may all be separate installations.

This makes the vulnerability an inventory problem too: an updated local PHP does not prove that production FPM or an older container image is safe.

I will cover the practical inventory in the next article.

A security advisory describes a possible attack path. It does not prove that a specific server has already been exploited.

Likewise, the absence of obvious errors in logs does not prove that a vulnerable runtime is safe.

Exposure assessment and incident investigation are different tasks and should not be merged without evidence.

Official PHP Security Advisory published on October 21, 2026:

Security advisory: Critical remote code execution vulnerabilities, update now

I intentionally do not include commands or step-by-step updating in this article.

The next question is practical: which PHP versions are actually running in production, development, Docker, and locally, how distribution backports affect the answer, and how to verify the application after a runtime update.

The main conclusion for now is that CVE-2026-109618 and CVE-2026-109619 exist at the PHP runtime layer, can lead to unauthenticated RCE, and affect PHP installations serving web requests.