The short version: our hosted clients were not affected
On 21 October 2026, the PHP project released emergency security updates for two critical vulnerabilities, since nicknamed "PHP2Shell". PHP is the language WordPress, WooCommerce, and a large share of the web are built on, so this was about as broad as a security issue gets.
If your site is hosted with us, there's nothing you need to do. We applied mitigations and patched our servers as soon as the fixes were published, and we have found no evidence that any client site was compromised. The rest of this post explains what the vulnerabilities were, why they mattered, and exactly what we did.
What is PHP2Shell?
PHP2Shell is the name given to two separate flaws in PHP itself, rather than in WordPress or any plugin:
- CVE-2026-109618: when PHP runs out of memory while it is still setting up an incoming request, the half-built request data could later be treated as valid during clean-up, corrupting memory.
- CVE-2026-109619: information belonging to one request could survive after its memory was released, so a later request handled by the same PHP worker could end up using that stale data.
Either flaw could allow an attacker to run their own code on the web server without logging in. Both were rated 9.2 out of 10 (critical). They affected almost every PHP version going back to PHP 5.4, and every common way of running PHP on a web server, including Apache with mod_php, PHP-FPM, and LiteSpeed.
In practical terms, a successful attack wouldn't just affect one website. It would give an attacker a foothold on the server itself, from which they could plant malware, steal data, or alter any site on that server.
How quickly it escalated
- 21 October: PHP publishes fixed versions (8.2.35, 8.3.36, 8.4.27, and 8.5.12). The UK's National Cyber Security Centre issues an alert the same day.
- 22 October: public proof-of-concept exploits begin to circulate.
- 26 October: the US Cybersecurity and Infrastructure Security Agency (CISA) adds both flaws to its Known Exploited Vulnerabilities list, confirming they are being used in real attacks.
Five days from disclosure to confirmed exploitation. That is the window anyone running PHP had to act in, and for servers that weren't patched promptly, the risk has only grown since.
What we did
We monitor security advisories for every part of the stack our clients' sites run on, not just WordPress and its plugins. When the PHP advisory landed, we acted the same day:
- Applied temporary mitigations immediately. Before patched builds were rolled out, we applied the server-level mitigations published alongside the advisory, closing off the main routes attackers would use to trigger the flaws.
- Patched PHP across every server. We updated all of our hosting servers to the fixed PHP releases and restarted every PHP worker so that no process was left running vulnerable code.
- Checked for signs of compromise. We reviewed server logs and scanned client sites for unexpected files, modified core files, and other indicators of attack. We found nothing to suggest any client site had been targeted successfully.
- Confirmed every site was working. Each hosted site was checked after the update to make sure the patch hadn't introduced any problems.
All of this was done before exploitation was confirmed in the wild. That's the point: by the time a vulnerability is on a government "known exploited" list, it's too late to start planning your response.
Why this matters when choosing a host
PHP2Shell is a good example of a risk that sits entirely outside your website. Your WordPress core could be fully up to date, every plugin patched, and your passwords strong, and the server underneath could still be vulnerable. On budget shared hosting, PHP versions are often left for weeks, and some hosts still run PHP versions that no longer receive any security updates at all. For those older versions, PHP only provided limited fixes for 7.4, 8.0, and 8.1, and nothing for anything older.
When we talk about managed WordPress hosting, this is what we mean: someone actively watching the whole stack and acting on the same day a critical issue is announced, rather than waiting for a ticket from a customer whose site has already been compromised.
Not hosted with us?
If your site is hosted elsewhere, ask your provider three questions:
- Which PHP version is my site running, and does it include the October 2026 security fixes (8.2.35, 8.3.36, 8.4.27, 8.5.12, or a vendor-patched equivalent)?
- When were the fixes applied?
- Have you checked the server for signs of compromise?
If you don't get clear answers, a security audit will tell you where you stand, or you can get in touch and we'll take a look.
