Let's build a website that works as hard as you do.
Get a fast, SEO-ready WordPress website built around your business, not a template.
At 7:45 on the morning of 22 October we checked which version of PHP our own website was running. The server had already installed the fixed version of PHP released the day before for two critical flaws now nicknamed “PHP2Shell”. The website was still running the old one. The fix was on the disk but not in memory, and it stayed that way until PHP was restarted. If your host tells you PHP is patched, this is the one thing worth checking yourself.
What happened
On 21 October the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, which it says “fix two critical vulnerabilities that can allow unauthenticated remote code execution”.[1] In plain English: someone who isn’t logged in could make a vulnerable server run their own code. The flaws are tracked as CVE-2026-109618 and CVE-2026-109619, and Patchstack reports that the PHP security team rates both Critical, at 9.2 out of 10.[3]
PHP says who is at risk: “all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.”[1] That covers almost every WordPress website. Details leaked on 20 October, before the planned release, and Patchstack’s timeline records “Multiple active exploitation incidents reported to Patchstack by hosting partners” at 07:34 UTC on 21 October, before the fix was out.[3]
Why there is nothing to update in WordPress
The flaws are in PHP itself, the language WordPress runs on, not in WordPress or a plugin. WordPress.org says so directly: “These vulnerabilities are not specific to WordPress and affect any server that hosts a PHP application. No WordPress update is required or planned for these issues.”[2] The fix comes from whoever runs your server: your web host, or you if you manage your own.
It is the same shape of problem as the Ghostscript flaw we wrote about on 16 October: a serious hole underneath WordPress that no plugin update can close.
What we checked on 22 October
We run the servers our clients’ websites live on, so this one was ours to fix. Every website on those servers runs PHP 8.5, which needs 8.5.12.
| What we checked | Result |
|---|---|
| PHP package installed on our main shared server | 8.5.12, the fixed version |
| PHP version our own website was actually running, 07:45 Malaysia time | 8.5.10, the vulnerable version |
| The same website after its PHP was restarted | 8.5.12 |
| A client website on the same server, before and after its restart | 8.5.10, then 8.5.12 |
| PHP restarted for every website on our four servers (with the owner’s go-ahead) | Done for every client website; one internal tool site is being retried. The fixed package is confirmed on our main server and is being confirmed on the three smaller ones |
| Every website checked afterwards | Loaded normally |
| One client website hosted with another company | PHP 8.3.35, which needs 8.3.36; flagged for that host to update |
Each website’s PHP runs as long-lived processes that load PHP once and then keep serving pages. Installing a new version replaces the files on the disk, but processes that started earlier keep running the old code until they are restarted. On our main server the fixed package arrived without that restart, so the websites carried on running 8.5.10 until we restarted PHP for each one.
Our view: a patch on the disk is not a patch in memory
“We’ve updated PHP” and “your website is running the fixed PHP” are two different statements. Usually they become the same thing within hours, because servers restart PHP for routine reasons. On a day when attacks were reported before the fix even shipped, hours matter. The only reading that counts is the version your own website reports, and it takes ten seconds to check.
This is also why we write down what we check rather than what we were told. Every website owner needs someone, whether a host, a developer or themselves, who checks the running version, not the installed one. We made the same point about who looks after the server in our guide to managed vs unmanaged hosting.
What not to do
- Don’t wait for a WordPress or plugin update. WordPress.org says none is required or planned for these flaws.[2]
- Don’t install a “PHP2Shell fix” plugin or paste in a code snippet. Patchstack’s advice: “Avoid unofficial ‘fix’ plugins and copy-pasted snippets. They are not verified and can break your site.”[3]
- Don’t stop at your host’s announcement. Check the version your website reports, as below.
- Don’t ignore an old PHP version. WordPress.org: “Versions of PHP prior to 8.2 no longer receive security updates from the PHP project.”[2]
Check it yourself
- Find your PHP version. WordPress.org: “Within WordPress, you can see which version of PHP your site runs under Tools > Site Health > Info > Server.”[2]
- Compare it with the fixed versions: 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or higher in the same series.[1] 8.4.26 needs updating; 8.4.27 is fine.
- If yours is lower, ask your host in writing: “Has PHP been updated to the fixed version for my site, and has PHP been restarted so my site is running it?” Then check Site Health again.
- If you are on PHP 8.1 or older, ask your host whether it provides a backported fix, or move to a supported version.[1]
- Watch for warning signs. Patchstack, citing the researchers who found the flaws, lists unusual multipart requests followed by memory-limit errors or repeated HTTP 500 errors, unexpectedly large or malformed PHPSESSID cookies, and unexplained PHP worker restarts.[3] If your host sees these, treat the server as possibly compromised.
Frequently asked questions
Do I need to update WordPress for PHP2Shell?
No. The flaws are in PHP, not WordPress, and WordPress.org says no WordPress update is required or planned. The fix is a PHP update on the server, done by your web host or by you if you manage your own server.
Which PHP versions fix PHP2Shell?
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026, or later versions in the same series. PHP 8.1 and older no longer get fixes from the PHP project; ask your host about a backported fix or upgrade.
My host says PHP is updated, but Site Health shows an older version. Why?
PHP runs as long-lived processes that keep the version they started with. After an update, the old version can keep running until PHP is restarted. Ask your host to restart PHP for your site, then check Tools, Site Health, Info, Server again.
If you think your site is affected
We are a web design and SEO studio, not a cybersecurity firm, and we don’t offer security investigations or malware clean-up as a service. If you think your site is affected, contact your hosting provider and, for a plugin problem, the plugin’s maker first. If your site may have been hacked, use a specialist security service; the sources listed below explain what they will look for.
What we write here is what we check on the websites we build and host for our own clients. If you are planning a new website, or want a second opinion on your current site’s design and SEO, request a free written review.
References
- PHP, “Security advisory: Critical remote code execution vulnerabilities, update now”, 21 October 2026. Accessed 22 October 2026.
- WordPress.org, “Critical PHP Security Release”, 21 October 2026. Accessed 22 October 2026.
- Patchstack (Mart Virkus), “Major security alert: PHP vulnerable to critical RCE, attacks ongoing”, 21 October 2026. Accessed 22 October 2026.
- Total Web Solutions records: PHP versions reported by websites on our servers, installed PHP packages on our main shared server, PHP restarts through the control panel, and a load check of every website afterwards, 22 October 2026.
