On 21 October 2026, the PHP project disclosed two critical security vulnerabilities that affect almost every website built on PHP, including WordPress. Here’s what they were, what we did on our hosting server, and why your website may still show the same PHP version number even though it has been fully patched.
What was the vulnerability?
The two flaws, CVE-2026-109618 and CVE-2026-109619, were nicknamed “PHP2Shell”. The PHP project rated them critical (9.2 out of 10). In the worst case, they could let an attacker run their own code on a vulnerable web server without logging in.
The fix hardens three parts of PHP:
- its memory allocator
- the parser that handles file-upload (multipart) requests
- the session upload-progress feature
PHP released fixed versions on 21 October: 8.2.35, 8.3.36, 8.4.27 and 8.5.12. PHP 7.4 is end-of-life, so the PHP project did not fix it.
Were any websites attacked?
Automated attacks started within minutes of the details going public. Overnight on 21–22 October, we saw a small number of attempts against our server. Our server’s firewall (Imunify360) had already received updated rules for this threat, and every request that matched them was blocked.
We then checked every targeted account for signs of a break-in: new or changed files, files planted in temporary or session folders, malware detections and PHP crashes. We found no evidence that any website was compromised.
What we did
Before the fix was released (20–21 October)
- Moved older sites off PHP 7.4. Most sites still on the unsupported PHP 7.4 were moved to PHP 8.3 and tested one by one. The two that still need 7.4 received CloudLinux’s patched 7.4 build (below).
- Kept the firewall current. Imunify360 installed its new rule sets for PHP2Shell automatically on 21 October.
- Watched for the patched packages. We checked CloudLinux’s repositories and status page regularly, so we could install the fix as soon as it was available.
Patching the server (Thursday 22 October, Brisbane time)
- 9:33 am: installed cPanel’s patched PHP 8.2 and 8.3, which run the server’s default PHP.
- 10:15 am: installed CloudLinux’s patched PHP 7.4.
- 10:22 am: installed CloudLinux’s patched PHP 8.2, 8.3, 8.4 and 8.5, which run almost every website on our server. These came from CloudLinux’s ELS repository, which had the fixed builds before its standard channels.
- About 10:25 am: restarted the web server, so every website started running the patched PHP.
After the restart, we checked sites across the server, and they were all working normally. We also confirmed in each package’s official change log that both vulnerabilities are fixed.
Why your PHP version number didn’t change
This is the part that has confused a few people, so we want to be very clear about it:
If your website still shows PHP 8.3.35 (or another “old” number), it is fully patched.
Our server runs CloudLinux, a hosting operating system that supplies the PHP our websites run on. When the PHP project released its fix as new version numbers (for example 8.3.36), CloudLinux took a different, standard approach. It applied the same security fixes directly to the PHP versions already installed. This is called a backport.
Backporting is normal practice for hosting and enterprise systems, because it delivers the security fix without the other changes that come with a new release. The catch is that PHP keeps reporting its original version number. You’ll see the old number in WordPress under Tools → Site Health, on a PHP info page, or in a security scanner. What changed is CloudLinux’s build number, the part after the dash in the package name:
| Your site shows | PHP project’s fixed release | Patched CloudLinux build on our server |
|---|---|---|
| PHP 7.4.33 | None (end-of-life) | 7.4.33-81 |
| PHP 8.2.34 | 8.2.35 | 8.2.34-7 |
| PHP 8.3.35 | 8.3.36 | 8.3.35-6 |
| PHP 8.4.26 | 8.4.27 | 8.4.26-5 |
| PHP 8.5.11 | 8.5.12 | 8.5.11-5 |
CloudLinux says this directly on its incident page for these vulnerabilities:
“Our packages carry the fix as a backport, so their version numbers stay below PHP’s.”
CloudLinux status page, 21 October 2026
So if a scanner or a developer tells you your site is “running a vulnerable PHP version” because it reports 8.3.35, that’s a false alarm caused by the version label. The protection is in place.
Do you need to do anything?
No. Everything was handled at the server level, and every website on our server has been protected since about 10:25 am on 22 October 2026, whatever version number it shows. As always, keeping your WordPress plugins and themes up to date is the best thing you can do for your site’s security.
If you have any questions, or your developer would like more technical detail, get in touch.