PHP2Shell: why your system needs a developer even when everything works

On 21 October an emergency release fixed two critical PHP vulnerabilities, and five days later the US cybersecurity agency listed them as actively exploited. What happened, who is affected, and why updating is not a one-off job.

It is easy to assume a working website or online store needs no attention. October's PHP2Shell shows why that is wrong: nobody touched the application code, the site ran without a hitch, and the server was still in critical danger. The risk did not come from a change in your code. It came from what was discovered about the PHP runtime your site is built on.

What happened?

The PHP project shipped an emergency release on 21 October for two vulnerabilities (CVE-2026-109618 and CVE-2026-109619). Both are rated 9.2 on CVSS v4, which is critical, and both can let an unauthenticated attacker run code on the server with the privileges of the web process.

What makes this especially unpleasant: according to Datadog's analysis, the attack needs only an unauthenticated HTTP POST to any PHP script, and PHP processes that request before your application code runs. Your application's login does not protect you, and neither does the quality of your code.

• 17 October: Amazon's honeypot network records an exploitation attempt, four days before public disclosure.

• 20 October: PHP announces the next day's release, and technical details leak ahead of the planned publication.

• 21 October: the fix ships, and watchTowr sees exploitation in its own honeypots the same day.

• 23 October: PHP discloses a third flaw (CVE-2026-115560) that the 21 October release does not fix.

• 26 October: the US agency CISA adds the two flaws to its catalog of actively exploited vulnerabilities and gives federal agencies three days to fix them.

For a complete picture, this does not mean every old server has been hacked. Rapid7 reports that the public exploits worked only under narrow conditions, with specific combinations of operating system, PHP version and web server. That is still no basis for a business decision. According to TechCrunch, the bugs were uncovered two years ago and judged to have no practical way of being exploited, until researchers at Calif found one with the help of an AI model. "Not exploitable right now" is not a permanent state.

Why the update button is not enough

The flaw is not in Laravel, WordPress or a Composer package. It is in the PHP runtime itself, so composer update fixes nothing here. On most sites, different people also look after the packages and the server, so it is easy for everyone to assume someone else has already done it.

The PHP version matters a great deal on its own. The fixed releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older get no official release. For 7.4, 8.0 and 8.1 the project published source-level backports only, so the options there are a distribution package, paid long-term support or moving to a supported version.

VirusTotal's internet survey found that among PHP servers disclosing their version, roughly 272,000 run a supported branch and about 758,000 run an end-of-life branch (5.4 to 8.1) where the affected feature is on by default. That covers only part of the visible internet, since most servers hide their version, and it does not measure how many machines are actually vulnerable. The ratio still says a lot. The next deadline is close as well: PHP 8.2 reaches end of life on 31 December 2026.

What updating means in practice

• Inventory. You need to know exactly what serves your requests. The command line php -v can show something different from what the web server uses, and PHP bundled in containers or other software counts too.

• Identifying the fix. Linux distributions often backport fixes without changing the version number, so check the package changelog, not just the number.

• Restarting. Google's guidance stresses restarting the actual PHP-FPM, Apache or other serving process, and container images need rebuilding. Old code can keep running after the package is installed.

• Temporary setting. Because of CVE-2026-115560, PHP recommends session.upload_progress.enabled=0 until the next bugfix release. It has to be set at server level, because ini_set() and .user.ini come too late. If your application uses upload progress tracking, that feature will stop working until then, so check first.

• Verification. After updating, walk through the critical flows: login, payment, forms, background jobs. Automated tests and a rollback plan help a lot here.

• Looking for traces. The fix does not remove anything an attacker already left on the server. Warning signs include the web process launching a shell, Allowed memory size ... exhausted errors logged with Unknown on line 0, and PHP processes crashing unexpectedly. If you find any, treat your keys and passwords as compromised.

Rapid7 notes that missing log entries are no proof that everything is fine, and Datadog writes that a successful attack can end with a normal HTTP 200 response while the process keeps running. That is why uptime monitoring cannot replace updating: a site can be perfectly available when it is no longer only yours. Settings and firewall rules buy time at best. In AWS's words, upgrading is the only complete remediation.

What does a developer who keeps an eye on things actually do?

The point is not firefighting, it is giving the firefighting a chance. About a day passed between PHP's announcement and the fix, and exploitation attempts were already under way. That leaves no time to look for a developer, ask for a quote and then learn an unfamiliar system.

• They follow security advisories and can judge what affects your system and how urgent it is.

• They know the environment: what runs where, what access they have, and what needs restarting.

• They update in small steps. For someone who updates regularly, an urgent fix is routine. For a system nobody has touched in years, the same fix becomes a version jump with compatibility issues at the worst possible moment.

• They plan version changes ahead. End-of-life dates are known in advance, so the move can be scheduled calmly rather than forced by a vulnerability.

• They keep records. There is a trace of what happened and when, which matters during an incident and towards your customers.

On shared hosting, patching PHP is usually the provider's job, but that does not take everything off your plate: choosing the PHP branch, keeping the application compatible and checking that the fix has really arrived all stay on your side.

Five questions to ask as an owner

• Who, by name, is responsible for reacting to a security advisory?

• Exactly which PHP version serves the site, and how long is it supported?

• When was the last update, and is there a record of it?

• How quickly can an urgent fix go live, and how do we roll back if something goes wrong?

• Has the PHP2Shell fix been applied, have the processes been restarted, and has anyone reviewed the logs?

If the first question has no name attached, start there. If your previous developer is no longer available, our article on taking over a system explains what to expect, and on the framework side our piece on upgrading Laravel can help.