PHP2Shell: What the Critical PHP Security Flaws Mean for Website Owners

Updated October 25, 2026

Two critical vulnerabilities in PHP prompted an urgent security response this week. Known collectively as PHP2Shell, the flaws can allow attackers to execute code on vulnerable servers without logging in.

The PHP project released emergency updates on October 21. Both vulnerabilities carry a critical severity score of 9.2 out of 10. They affect the PHP runtime itself, rather than a particular website plugin or framework. The PHP Foundation’s account of the incident explains why fixing them became a priority.

What went wrong?

The first vulnerability, CVE-2026-109618, concerns how PHP handles running out of memory. Under certain conditions, a failed allocation can leave internal data only partly initialized. PHP’s cleanup routines may then use that invalid data, creating an opportunity for remote code execution.

The risk is particularly serious with Apache’s mod_php integration: a demonstrated attack can reach the vulnerable behavior before the website’s own application code runs. PHP-FPM deployments must not be assumed safe either; exposure depends on the execution path and application behavior. PHP’s technical advisory describes these differences.

The second vulnerability, CVE-2026-109619, involves internal state surviving after the memory it refers to has been freed. When the same worker handles another request, it can access that stale state—a memory-safety problem called use-after-free. The second advisory documents how this can lead to code execution with the web worker’s permissions.

Which PHP versions contain the fixes?

The security releases addressing the two original vulnerabilities are:

• PHP 8.2.35
• PHP 8.3.36
• PHP 8.4.27
• PHP 8.5.12

These are the fixed upstream releases listed in PHP’s advisory. Administrators should install these or a newer supported release containing the fixes.

Linux package versions need more careful interpretation. Distributions can backport security fixes without adopting the same upstream version number. For example, Ubuntu lists a patched PHP 8.3 package for Ubuntu 24.04 as 8.3.6-0ubuntu0.24.04.13. Check the complete package version against your vendor’s security notice, not just the first three numbers. Ubuntu’s patch guidance also stresses restarting the applications using PHP so they load the updated components.

The October 23 follow-up matters too

On October 23, PHP published additional guidance concerning CVE-2026-115560 and its session upload progress feature.

This issue requires an unusual combination: upload progress remains enabled, and an application changes its session serialization handler from php_binary or php_serialize to php at runtime before starting a session.

PHP recommends setting session.upload_progress.enabled=0 until the next regular bugfix release to close this unlikely attack path. Applications that never change the serialization handler at runtime can keep the feature enabled, according to the advisory.

This is a specific follow-up condition, not evidence that the emergency updates failed across all installations. Administrators should nevertheless review the October 23 notice, including on systems already patched earlier in the week.

Serious risk does not mean every website was compromised

Initial warnings were understandably urgent, but exploitation attempts, working demonstrations and confirmed compromises are different things.

In its October 23 update, the Dutch National Cyber Security Centre said exploitation appeared more complex—and large-scale exploitation less likely—than initially estimated. It still advised immediate patching. That is an important distinction: a revised assessment of attack difficulty is not a reason to leave vulnerable systems online. NCSC-NL’s updated assessment sets out the latest position.

How we responded at WhatsMyIP.com

Our team carried out emergency PHP patching on Wednesday, October 21, covering the active PHP systems identified in our inventory. We restarted the relevant web services and performed post-update checks.

For website owners, the practical task is to confirm that the PHP runtime actually serving visitors contains the fixes. A command-line version check alone may not establish what every website or worker is running. If your hosting is managed, ask your provider to confirm the installed security update, the necessary restarts and whether the October 23 follow-up applies to your configuration.