On October 21, 2026, the PHP project released emergency updates for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Details had leaked publicly the day before, and the release was brought forward to get the fixes out. Security researchers have started calling the pair PHP2Shell.
Both flaws let an attacker run their own code on a server without logging in to anything. Each carries a CVSS 4.0 score of 9.2 out of 10. The Canadian Centre for Cyber Security issued an alert the same day and says proof-of-concept code is reportedly available.
The problem is on the server, not in your website
PHP is the programming language behind a large share of business websites, including every WordPress site. Your website is a set of files written in PHP. The server has its own installed copy of PHP, called the interpreter, which reads those files and turns them into the pages your visitors see.
These flaws are in the interpreter. Nothing in your theme, plugins or content caused them, and nothing you change in your website will fix them. Updating WordPress or a plugin does not touch the interpreter. The fix is an update to PHP on the server, and that is your hosting provider’s job.
The WP2Shell issue we wrote about earlier was different: the flaw was in WordPress itself, and a WordPress update fixed it.
Why taking a website offline does not help
When a story like this breaks, some site owners take their website offline or put it into maintenance mode until things settle. For this one, all that does is take the business offline while the server keeps running unpatched PHP.
The PHP project says there are no complete mitigations and updating is the only safe choice. On some server setups the attack happens while PHP is still handling the incoming request, before any of the website’s own code has run. WordPress maintenance mode is still WordPress, so a site in maintenance mode is still passing every request to the same interpreter.
On a shared or managed server, that one copy of PHP runs every site on the machine. Taking one website down leaves the server unpatched for all of them, and a compromised server can put every site on it at risk, including the one that was switched off.
The fixed versions
The PHP project’s fixed releases are:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
PHP 8.1 and older no longer receive official releases. The PHP project published minimal fixes for 7.4, 8.0 and 8.1 for anyone who builds PHP from source, and some hosting platforms supply their own patched builds. PHP 8.2 reaches end of life on December 31, 2026, so a site on 8.2 or older should be planning an upgrade either way.
Servers running CloudLinux use its own builds of PHP. CloudLinux’s first fixed builds, released within a day of the PHP project’s, kept the version number they already had and added the fix to it:
- alt-php85 8.5.11-5
- alt-php84 8.4.26-5
- alt-php83 8.3.35-6
- alt-php82 8.2.34-7
- alt-php81 8.1.34-39
- alt-php80 8.0.30-69
- alt-php74 7.4.33-81
Patched builds were also released for its older versions back to PHP 5.2. There is no fix for PHP 4.4 or 5.1. The cPanel builds CloudLinux supplies, named ea-php, were patched the same way, for example ea-php85 8.5.11-2.el8.cloudlinux.1 on CloudLinux 8.
A day later, CloudLinux moved its alt-php 8.2 to 8.5 packages on CloudLinux 8 and 9 up to the PHP project’s numbers:
- alt-php85 8.5.12-1
- alt-php84 8.4.27-1
- alt-php83 8.3.36-1
- alt-php82 8.2.35-1
That change only brought the numbers in line. The earlier builds were already patched.
A lower version number does not always mean unpatched
Because of how those first builds were numbered, a CloudLinux server can show PHP 8.5.11 or 8.2.34 and still have the fix. CloudLinux says its packages “contain the fix for both CVEs, even though the PHP version number is lower.” Scanners and version checkers that only compare version numbers can flag these servers as vulnerable when they are not. On a CloudLinux server, the build number after the dash shows whether PHP is patched, not the version number on its own.
If someone else hosts your website
Ask your host whether PHP on your server has been updated for CVE-2026-109618 and CVE-2026-109619, and when. Ask which PHP version your site runs as well. Anything on 8.1 or older no longer gets updates from the PHP project and should be upgraded.
How we handle it
On the servers ALPHA V3 manages, security updates to PHP and the server software around it are applied as soon as they are released, and both of these vulnerabilities have been patched. Keeping server software up to date is part of what our managed hosting and maintenance plans cover.
Sources
- Canadian Centre for Cyber Security: AL26-026, Critical vulnerabilities impacting PHP (October 2026)
- PHP: PHP 8.5.12 release announcement (October 2026)
- PHP: news and security releases
- CloudLinux: PHP CVE-2026-109618 and CVE-2026-109619 (October 2026)
- watchTowr: PHP CVE-2026-109618 FAQ (October 2026)
- Huntress: php2shell, leaked critical PHP vulnerabilities (October 2026)
