PHP2Shell: Understanding the Critical PHP Vulnerabilities Disclosed in October 2026

Published: October 22, 2026
Category: PHP, Cybersecurity, Application Security
CVE IDs: CVE-2026-109618, CVE-2026-109619
Severity: Critical — CVSS v4.0 score of 9.2 for each vulnerability

Introduction

On October 21, 2026, the PHP project released security updates addressing two critical vulnerabilities in the PHP runtime, collectively known as PHP2Shell.

Tracked as CVE-2026-109618 and CVE-2026-109619, these vulnerabilities involve memory corruption and stale internal memory state. Under vulnerable conditions, an unauthenticated attacker may be able to trigger remote code execution through specially crafted HTTP requests.

The disclosure is particularly relevant to developers and administrators responsible for internet-facing PHP applications, including Laravel projects, WordPress installations, and other PHP-based systems.

Official advisory: https://www.php.net/archive/2026.php

What is PHP2Shell?

PHP2Shell is the name used for two vulnerabilities affecting PHP's internal runtime behavior.

Unlike a vulnerability limited to a particular application route, these issues exist in the PHP engine itself. Consequently, updating application code or Laravel dependencies alone does not resolve the underlying problem.

The vulnerabilities involve two related but distinct conditions.

CVE-2026-109618: Out-of-memory handling and memory corruption

This vulnerability concerns how PHP handles an out-of-memory condition during request processing.

Under certain conditions, an allocation failure can interrupt PHP while internal request data is only partially initialized. Subsequent cleanup may incorrectly treat that data as valid, creating a potential memory-corruption condition.

Depending on the circumstances, an attacker may be able to exploit this behavior to execute unauthorized code.

CVE-2026-109619: Stale state and use-after-free

This vulnerability involves internal state that can outlive the memory backing it.

When request-owned memory is freed, references to that memory may remain in a global state. A later request handled by the same worker can potentially encounter the stale state before normal initialization resets it.

This use-after-free condition may also lead to remote code execution under vulnerable conditions.

Why can remote code execution be dangerous?

Remote code execution occurs when an attacker can cause a system to execute code or commands chosen by the attacker.

If exploitation succeeds, the consequences depend on the privileges and isolation of the affected PHP process.

Potential impacts include:

Unauthorized access to data available to the PHP process.
Exposure of database credentials, environment variables, and application secrets.
Unauthorized changes to application files.
Installation of malicious scripts or other persistence mechanisms.
Further attacks against services accessible from the compromised server.

A successful exploit does not automatically grant unrestricted root access. The attacker's capabilities depend on process privileges, operating-system permissions, container isolation, and other security controls.

Are Laravel applications affected?

Laravel applications may be exposed if their underlying PHP runtime is vulnerable.

Laravel provides many application-level security features, including request validation, authentication, authorization, middleware, and protection against common web vulnerabilities. However, these protections cannot independently fix a flaw in the PHP runtime.

The official PHP advisory identifies web-serving configurations including PHP-FPM, Apache with mod_php, CGI, FrankenPHP, and LiteSpeed as potentially affected. It identifies particular concern with mod_php because a demonstrated exploit can trigger the vulnerability before application code executes.

For Laravel developers, this means runtime patching must be treated separately from application dependency updates.

Running composer update does not patch the PHP engine.

Which versions contain the security fixes?

The PHP project published the following fixed releases on October 21, 2026:

| PHP branch | Fixed release | |---|---| | PHP 8.5 | 8.5.12 | | PHP 8.4 | 8.4.27 | | PHP 8.3 | 8.3.36 | | PHP 8.2 | 8.2.35 |

For PHP 8.1 and older, administrators should consult their operating-system distribution or hosting provider for backported security fixes. These branches no longer receive regular updates from the PHP project, so upgrading to a supported release is advisable.

Always verify package status with your vendor, especially when using distribution-managed PHP packages.

How to check your PHP installation

Start by checking the CLI version:

php -v

For PHP-FPM, try:

php-fpm -v

The PHP-FPM executable may have a version-specific name, such as php-fpm8.3.

However, the CLI version is not necessarily the version serving production traffic. Check the configured PHP-FPM pool, web-server integration, container image, or hosting control panel as appropriate.

Avoid publishing a publicly accessible phpinfo() page to inspect production configuration. If one is already exposed, remove or restrict it.

Recommended remediation steps

1. Identify affected systems

Inventory PHP installations across production servers, staging environments, containers, and third-party products that bundle PHP.

Prioritize internet-facing systems.

2. Apply a security-fixed release

Upgrade to the appropriate patched version or install a security package confirmed by your operating-system vendor.

Test the update in staging where feasible, but do not allow routine deployment procedures to create an unnecessary delay for an internet-facing critical vulnerability.

3. Restart PHP workers

After patching, restart the applicable PHP-FPM service, Apache service, or other PHP workers so that the running processes load the updated runtime.

4. Investigate possible compromise

Patching prevents continued exposure to the fixed vulnerability, but it cannot reverse a compromise that has already occurred.

Review web-server and application logs, process activity, file modifications, authentication events, and unexpected outbound connections. Escalate suspicious findings to your security team and follow your incident-response procedures.

5. Apply temporary mitigations if patching is delayed

The official PHP advisory describes configuration-based measures that can reduce exposure to specific attack paths. These may include changes to memory-limit handling, request-size limits, and session upload progress settings.

Such measures are incomplete and can affect application behavior. Follow the official advisory and validate any configuration change before deployment. Patching remains the preferred remediation.

Security lessons for PHP developers

PHP2Shell highlights several practical lessons:

Application-level security and runtime security are separate responsibilities.
Dependency updates do not replace runtime and operating-system patching.
Knowing the version running in production is essential.
Critical security updates require a defined incident-response and deployment process.
Server isolation and least-privilege permissions can reduce the impact of successful exploitation.
Patching should be followed by an assessment of whether compromise occurred before the fix was applied.

Conclusion

PHP2Shell demonstrates why secure application development must extend beyond application code.

For developers working with PHP and Laravel, maintaining a patched runtime is a fundamental part of production security. Identify exposed systems, apply the appropriate security update, restart affected services, and investigate suspicious activity where necessary.

Official reference: https://www.php.net/archive/2026.php

Additional technical guidance:

https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619
https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/