On October 21, 2026, the PHP team released urgent security updates to fix two vulnerabilities in the PHP engine: CVE-2026-109618 and CVE-2026-109619, sometimes collectively referred to as PHP2Shell.
According to the PHP project, these vulnerabilities could allow remote code execution without authentication. They affect PHP itself; therefore, a website could be compromised even if its CMS, extensions, and application code are up to date.
The update is the only complete fix. Configuration settings can mitigate certain risks but are no substitute for installing the patch.
Two vulnerabilities, two mechanisms
Both vulnerabilities involve memory management when PHP abnormally terminates the processing of a request.
- CVE-2026-109618: Out-of-Memory (OOM) Corruption
An out-of-memory error can interrupt processing while some internal request data is only partially initialized. The request cleanup process may then treat this data as if it were valid. - CVE-2026-109619: Stale global state
Internal data associated with a request may persist after the memory containing it has been freed. A subsequent request, processed by the same process, may then reuse this state before it is properly reset.
Both vulnerabilities are rated critical and may, depending on the circumstances, lead to remote code execution. The second vulnerability may also expose data present in the PHP process’s memory. The actual impact depends, in particular, on the deployment model and configuration.
Who is affected?
You must verify the version of PHP that is actually executing the requests, not just the version of the CMS or applications. Also consider containerized environments, base images, virtual machines, runtimes managed by a hosting provider, and software that includes its own version of PHP.
Apache with mod_php
According to available information, the attack vector related to CVE-2026-109619 can be exploited with mod_php, even if the application does not call session_start(). Therefore, you should not assume that a site is protected simply because it does not explicitly use sessions.
PHP-FPM and Other Deployments
With PHP-FPM, vulnerability depends in particular on the configuration of the CGI frontend and the values it passes. Some of these can trigger a diagnostic before the request is fully initialized. Since it can be difficult to confirm the absence of this attack vector in a given configuration, it is best to treat FPM installations as potentially affected until verified.
Since the vulnerability lies within PHP, having an up-to-date CMS or extension is not sufficient to fix the problem.
Fixed Versions
The PHP project released the following versions on October 21:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
PHP 8.1 and earlier versions no longer receive fixes from the PHP project. However, some vendors or distribution maintainers may offer backports. Check the status with your vendor and make sure the installed package actually contains the fix: the version number displayed may differ from that of the official versions listed above.
For servers running a Linux distribution, install the patched packages provided by that distribution. For containers, update the image containing PHP, then rebuild and redeploy the container: patching the host does not automatically update PHP within the image. If your version of PHP is no longer supported, consider migrating to a supported branch or simply shutting down the service.
What should you do now?
- Take inventory of all PHP installations, including those in containers, base images, and hosted services.
- First, update the services accessible from the Internet.
- Restart or redeploy the affected processes after the update to ensure they are using the patched libraries and executables.
If you cannot apply the fix immediately, reduce exposure: restrict network access or temporarily take the service offline. If PHP is managed by your hosting provider, ask them to confirm that the fix has been applied.
Temporary Measures: Useful, but Incomplete
The PHP project specifically mentions adjustments that could limit certain scenarios:
1session.upload_progress.enabled=Off
If PHP is ran using PHP-FPM :
1php_admin_flag[session.upload_progress.enabled] = off
This setting addresses the vulnerability associated with CVE-2026-109619. Other measures mentioned in the advisories include, depending on the version and configuration:
1fatal_error_backtraces=02memory_limit=-1
It is also possible to reduce post_max_size and max_input_nesting_level based on the application's actual needs.
These settings have different effects and must be evaluated in the context of each service. In particular, changing the upload limits may disrupt features that accept files. None of these measures constitutes a complete fix: install the PHP update as soon as possible.
Logs and Preparation for a Post-Incident Analysis
Monitoring recommendations do not necessarily make it easy to identify all attempts. It is still useful to maintain sufficiently detailed PHP logs to facilitate a post-incident analysis:
1log_errors=On2error_log=/chemin/adapté/php-error.log3error_reporting=E_ALL
Verify that the selected path is accessible to the PHP process, that the logs are retained, and that they are not publicly exposed. Logging aids in investigation but does not prevent exploitation.
Exploits Already Observed in the Wild
Several exploits have already been published, and the number of references is growing.
If you use such an exploit to search for vulnerable deployments in your information system, you should generally audit the code to verify that it does not contain any actual malicious code.
Furthermore, isolated actors have been exploiting these vulnerabilities since October 17. It is therefore advisable to conduct a post-mortem analysis on sensitive environments.
The vulnerabilities are already being exploited, and exploitation can be automated on a large scale.
Indicators of compromise are being shared by entities such as Amazon. However, detection efforts should not be limited to these indicators alone.
The Problem of Obsolescence
One of the factors that makes this pair of vulnerabilities so impactful is the problem of obsolescence, which is very specific to PHP.
In fact, major releases of PHP introduce changes that break the language’s compatibility with certain features used by many applications.
As a result, it is still very common to find versions such as PHP 5 or PHP 7 in production that have not been maintained for several years, or even a decade in some cases.
Since these branches are also vulnerable, the barrier to upgrading may turn the fix into a major adaptation effort. In this sense, PHP2Shell can be considered similar to Log4Shell in that this risk is expected to persist over time.
Conclusion
Identify all your PHP installations and apply the patched packages as soon as possible, prioritizing services exposed to the Internet. PHP2Shell affects the runtime engine itself: updating a website or CMS without updating PHP is not sufficient.