On 21 October 2026 the PHP project released emergency security updates for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, which have been nicknamed “PHP2Shell”. They affect PHP, the software behind a very large share of the web, including WordPress sites. This is what happened, what we did about it, and what you should check.
What the vulnerabilities are
Both flaws are rated 9.2 out of 10 (critical) on the CVSS v4.0 scale. They allow an attacker to run their own code on a server without needing to log in, which is known as unauthenticated remote code execution. In practice that can mean a website taken over, data stolen, malware installed, or the server used to attack others.
According to the US Cybersecurity and Infrastructure Security Agency (CISA), the problem affects all PHP installations that serve web requests, including Apache with mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. That makes it relevant to almost anyone running a PHP website or web application, whether they host it themselves or someone else does.
Why it is urgent
CISA added both vulnerabilities to its Known Exploited Vulnerabilities catalogue on 26 October 2026, which means attackers are already using them. The PHP project’s own advice ahead of the release was to prepare in advance so that systems could be updated the moment the fix was available, and that is exactly what matters here: the time between a fix being published and a system being patched is the window attackers use.
The fixed versions
- PHP 8.5: update to 8.5.12
- PHP 8.4: update to 8.4.27
- PHP 8.3: update to 8.3.36
- PHP 8.2: update to 8.2.35
CISA also advises taking PHP systems offline if they cannot be updated promptly, or if they run PHP 8.1 or an earlier version that no longer receives security fixes, until they are patched or upgraded.
What we did
We updated our own systems the instant the fixed versions were available. For customers, we rolled the updates out across our customer estate through our centrally managed system, which let us make the changes quickly, consistently and securely rather than system by system.
Between the warning and the fix, we also took steps to protect customer data:
- Backups. We made sure current backups were in place, so that data could be recovered whatever happened.
- Restricted access. We tightened access on our firewalls to reduce exposure while the fix was rolled out.
- Systems taken offline where needed. Where a system could not be made safe straight away, we took it offline rather than leave it exposed.
- Extra monitoring and mitigation. We increased monitoring for suspicious activity and applied additional protective measures.
We found no sign that any customer data was affected.
What you should check
If you run, or rely on, anything built on PHP, work through this list:
- Find out where PHP is used. Your website, any web application, and software that bundles its own copy of PHP all count. If someone else hosts it for you, ask them directly whether it has been updated.
- Patch the systems facing the internet first. Those are the ones attackers can reach.
- Check your version. If you are on PHP 8.1 or earlier, you need to upgrade, not just patch.
- Watch for signs of trouble. CISA advises looking for PHP worker processes that start command shells or download tools, and for unexpected changes to files.
- Keep tested backups. If the worst happens, a backup you have actually restored is what gets you back quickly.
Sources
The facts about the vulnerabilities come from CISA’s alert and the PHP project’s announcement. If you would like help, see our cybersecurity and websites and hosting services, or talk to us.