A critical security issue in PHP deserves attention from every developer and server administrator maintaining PHP applications.

On October 21, 2026, the PHP development team released emergency security updates addressing two critical vulnerabilities that could allow an unauthenticated attacker to execute code on a vulnerable server. These vulnerabilities are commonly known as PHP2Shell and are tracked as CVE-2026-109618 and CVE-2026-109619.

Both vulnerabilities received a CVSS 4.0 severity score of 9.2 out of 10. The PHP team released fixed versions across its supported PHP 8.x branches.

What makes this issue particularly important is that the problem exists in the PHP runtime itself, rather than being limited to a particular Laravel application, WordPress plugin, or custom PHP project.

In other words, even if your application follows good coding practices, you still need to check whether the underlying PHP installation has been patched.

Let's understand what happened and what we should do about it as developers.

What is the PHP2Shell attack?

PHP2Shell is the name used to describe two related critical vulnerabilities in PHP's request-processing and memory-management behavior.

Under the right conditions, an attacker can send a crafted HTTP request to a vulnerable PHP server and potentially execute arbitrary code without authenticating first.

Remote code execution, commonly called RCE, means an attacker can cause a vulnerable system to execute instructions of their choosing. Depending on the permissions of the affected process and the server's configuration, this could expose application files, database credentials, customer data, or other resources accessible to that process.

The important distinction is that these vulnerabilities affect PHP itself. They are not simply another example of SQL injection, cross-site scripting, or an insecure Laravel controller.

The PHP security advisory identifies two separate issues:

CVE-2026-109618: Remote code execution associated with out-of-memory corruption.

CVE-2026-109619: Remote code execution associated with stale global state and memory that has already been freed.

Both require immediate attention on affected systems.

Why is this issue different from an ordinary application vulnerability?

Consider a typical Laravel application.

When a browser sends a request, the request generally passes through the web server and PHP runtime before your Laravel application handles it.

A simplified request flow looks like this:

Browser or API client
        |
        v
Nginx or Apache
        |
        v
PHP runtime / PHP-FPM
        |
        v
Laravel bootstrap
        |
        v
Middleware
        |
        v
Controller
        |
        v
Database or other services

Most application-level security checks happen after PHP has started processing the request.

For example, Laravel validation can reject invalid input. Authentication middleware can prevent an unauthenticated user from reaching a protected route. Authorization policies can restrict access to particular records.

Those controls remain important, but they do not repair a memory-corruption vulnerability inside PHP.

Depending on the PHP execution mode and attack path, the vulnerable behavior can occur before the application reaches Laravel's middleware or controller.

This is why updating Composer packages alone is not a solution. The PHP runtime and its security updates need to be addressed separately.

Which PHP applications are affected?

The PHP project's security advisory covers installations serving web requests, including:

PHP-FPM.

Apache with mod_php.

PHP-CGI.

FrankenPHP.

LiteSpeed-based PHP installations.

The PHP security team has identified Apache mod_php as the highest-risk configuration for a demonstrated attack path. However, developers using PHP-FPM or another supported execution model should not assume their systems are automatically safe.

The potential exposure includes applications built with:

Laravel and other PHP frameworks.

WordPress.

Drupal.

Joomla.

Custom PHP applications.

PHP-based APIs and business applications.

The specific framework is not the determining factor. The central question is whether the application processes web requests using an affected PHP runtime.

Was the vulnerability being exploited?

This is another reason not to postpone updates.

Amazon Threat Intelligence reported an attempted PHP2Shell exploitation against its MadPot honeypot network on October 17, 2026, four days before public disclosure.

Amazon subsequently observed additional attempts and proof-of-concept activity around the time the vulnerabilities were disclosed. Its report notes that the earlier telemetry does not establish that every observed attempt would have succeeded against a real-world server.

The practical lesson is straightforward: public disclosure is not necessarily the first date on which attackers begin targeting a vulnerability.

For administrators investigating a potentially exposed server, it is therefore sensible to examine relevant logs from at least October 17, rather than starting the investigation on October 21.

How can developers check their PHP version?

Start with the PHP installation used by your application.

Run:

php -v

This displays the PHP version used by the command-line interface.

Next, identify the installed PHP configuration:

php --ini

On a Linux server using PHP-FPM, you can also check the available FPM services:

systemctl list-units --type=service --all | grep -E 'php.*fpm|apache2'

These commands help identify the environment, but they do not independently prove that every web-facing PHP installation is patched.

For example, a server may have PHP 8.2 and PHP 8.1 installed simultaneously. The command-line interface could use PHP 8.2 while a website still runs through PHP 8.1-FPM.

Similarly, a Linux distribution may backport a security fix without adopting the same upstream version number. In that situation, the distribution's package security status matters as well as the reported PHP version.

Make sure you check the actual runtime used by each application.

Which PHP versions contain the fix?

The PHP project released the following fixed versions on October 21, 2026:

These are the upstream PHP release versions listed in the official advisory. Linux distributions may provide their own package versions containing backported fixes. PHP 8.1 and older are no longer supported by the upstream project, although some distributions and long-term-support vendors may supply separate security updates.

Do not assume that an installation is safe simply because it is relatively recent. Check the fixed release or the security status of the package supplied by your operating system vendor.

Does updating Laravel fix PHP2Shell?

No. Updating Laravel and updating PHP are different tasks.

For example, a developer might run:

composer update

This updates eligible Composer dependencies according to the project's dependency constraints. It does not, by itself, replace an affected PHP-FPM binary or patch PHP installed by the operating system.

A better maintenance approach is to check both layers:

Application dependencies: Review Composer dependencies and apply relevant security updates.

PHP runtime: Update the PHP installation to a fixed release or a vendor package containing the relevant security patches.

Web server and workers: Restart or redeploy the appropriate processes so they use the updated binaries.

Verification: Confirm the actual PHP runtime used by the application and test the major application workflows.

These are complementary tasks, not alternatives.

Final thoughts

PHP2Shell is a reminder that securing an application involves more than writing safe controllers and validating user input.

A Laravel application can have authentication, authorization, prepared database queries, and a well-designed middleware structure while still depending on a vulnerable PHP runtime.

As developers, we need to monitor security announcements for the frameworks, libraries, runtimes, operating systems, and services our applications rely on.

For this particular issue, the priority is to identify every affected PHP installation, apply a verified security update, restart the relevant processes, and investigate any signs of suspicious activity.

The most important step is to patch the PHP runtime. Do not rely on application-level validation or a web application firewall as a substitute for the fix.