PHP2Shell: a critical PHP flaw and what your business should do now

What happened

PHP is the programming language behind a large share of the web: WordPress, many online shops, customer portals and the web interfaces of internal systems. On 21 October 2026, the PHP project released security updates fixing two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, together known as PHP2Shell.

Both are rated 9.2 out of 10 for severity. An attacker can exploit them remotely, without logging in, and run their own code on the server. The flaw is in PHP itself, not in a particular website or plugin, so every unpatched PHP installation that serves web requests is at risk.

Why this can’t wait

Details leaked before the fixes were released. Amazon’s threat intelligence team saw the first exploitation attempt on 17 October, four days before disclosure. Proof-of-concept exploits appeared on the day the fixes came out, and the team has since reported broad exploitation attempts.

It is not clear how many attempts succeeded. Slovakia’s national CSIRT, SK-CERT, had not confirmed active exploitation on the day of release. With a flaw this widespread, though, you should assume attack attempts will reach your server too.

The flaws were also found by researchers using AI models. According to them, AI also helped them develop working exploits and adapt them to different applications within hours. In their view, complexity is ceasing to be a reliable barrier against exploitation.

Which versions are fixed

The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. What that means for your server depends on which PHP version it runs today.

• PHP 8.2 to 8.5: Update to the latest release in the same branch. PHP 8.2 only receives security fixes until 31 December 2026, so also plan a move to a newer branch.
• PHP 8.1 and older: The PHP project has not released an official update for these versions. Some Linux distributions and extended-support vendors may offer a fix. Otherwise, the only solution is to move to a supported version.
• Updating your website is not enough: A new version of WordPress, your shop software or plugins will not fix the flaw. PHP itself must be updated on the server, and all its processes restarted.
• Workarounds only buy time: According to the PHP project, no configuration change fully removes the flaw. Temporary settings and web application firewall rules reduce the risk, but they do not replace the update.

What to do today

Many companies do not run their own servers. Their website sits with a hosting provider, their shop on a ready-made platform, or an agency manages both. Your job is to find out who is responsible for each system and get a clear answer from them.

• List everything that runs on PHP: Your company website, online shop, customer portal, intranet and the web interfaces of internal systems. This also includes off-the-shelf products that contain PHP.
• Ask whoever runs it: Ask your hosting provider, agency or IT supplier: Which PHP version do we use? When was it updated to a fixed version? Were all PHP processes restarted afterwards?
• Check hosted platforms: If your website or shop runs on a platform operated by a provider, the provider handles the update. Check that they have confirmed it.
• If you can’t update right away: Consider taking the service offline temporarily or restricting access to it from the internet. SK-CERT recommends this especially for sensitive systems and services that cannot be updated quickly.
• Look for signs of an attack: Ask your administrator to review server logs from at least 17 October, looking for unexpected files, processes or new accounts. If anything looks suspicious, change the passwords and access keys stored on the server.

How to prepare for the next flaw

PHP2Shell will not be the last critical vulnerability. What matters is how quickly you can respond: whether you know what runs where, who manages it and how fast they can deploy a fix.

Agree with your website administrator and suppliers on how quickly they deploy critical security fixes, and keep track of the software versions your systems depend on. Treat a system that cannot be updated as technical debt with a deadline and an owner, not as something that can wait.