Last updated Thursday 22 October 2026. This is a developing story and we’ll update this post as new information emerges.
Quick summary
- A critical security flaw, nicknamed “PHP2Shell”, was found this week in PHP, the language behind WordPress and most of the web.
- The fix was applied to the sites we host and manage on the day it was released, and we’ve verified it across our whole fleet.
- Our follow-up checks have found no sign that any client site was affected.
- You don’t need to do anything, though do tell us if anything on your site looks odd.
What happened
On 21 October, the PHP project published fixes for two critical security vulnerabilities in the language itself, known as CVE-2026-109618 and CVE-2026-109619. Both are rated 9.2 out of 10 in severity.
PHP is the programming language that runs WordPress, and with it the large majority of the world’s websites, including those of our clients. In plain terms, the flaws could let an attacker send a specially crafted web request that tricks a server into running the attacker’s own code. No password or login is needed, which is what makes it so serious: any website running an unpatched version of PHP is a potential target, regardless of how well the website itself is built.
The fix is to update PHP to one of the patched versions (8.5.12, 8.4.27, 8.3.36 or 8.2.35). That’s a job for whoever runs the server, not something website owners or editors can do themselves, which is why the responsibility here sits with us and our hosting partners.
What you may have seen in the news
The coverage looks alarming, but the most dramatic part of the story, websites “going dark” around the world, is largely organisations being careful rather than organisations being hacked. Security researchers have nicknamed the pair of flaws “PHP2Shell”, and governments in the Netherlands, Finland, France, Canada and Australia temporarily took websites offline while the fix was prepared and applied, in line with official advice to patch immediately or take systems offline until you can. The UK’s National Cyber Security Centre issued an alert urging organisations to find their PHP systems, update straight away, and check for signs of compromise where updating was delayed. There were also reports of attackers already probing the flaws, which is why everyone moved so quickly. The story is still running: the BBC has live coverage and the Guardian a useful plain-English explainer.
One detail worth knowing for WordPress site owners: WordPress’s own automatic updates do not update PHP. As the security firm Wordfence pointed out, the fix has to be applied by whoever runs the server. For our clients, that’s exactly what happened, as set out below.
A curious footnote: the flaws had apparently sat unnoticed in PHP’s code for years and were uncovered by security researchers using AI-based analysis. Expect more discoveries like this, in both directions, as AI tools get better at reading code.
What we’ve done for the sites we manage
Every website we host and manage is now running a patched version of PHP, and our follow-up checks have found no sign that any site was affected. Here’s the timeline.
- Monday 20 October. PHP’s developers gave advance warning that critical security fixes were coming, which gave hosts time to prepare.
- Tuesday 21 October. The fixed versions of PHP were released at 3pm UK time. We had already spoken to both of our hosting partners, Kinsta and Cloudways, whose engineers applied the patched versions across the servers they manage the same day. We also emailed all clients that morning to explain what was happening and ask you to flag anything unusual after the update.
- Wednesday 22 October onwards. We verified through our monitoring tools that the sites we manage are reporting patched PHP versions, rather than taking the hosts’ word for it. For clients who asked for extra assurance, we went further still, logging in at server level to verify the integrity of the WordPress files, sweep for anything recently added or changed that shouldn’t be there, and review administrator accounts. Those checks came back clean, and the same inspection is available to anyone: if you’d like us to run it on your site, just ask. Where useful, we’ve also tightened the monitoring settings in the security software running on client sites.
The window of risk was small. The flaws became public knowledge on the Tuesday and the sites we manage were patched the same day. But “small” isn’t “zero”, which is why we’ve done the follow-up checks rather than assuming all is well.
Is there anything you need to do?
If we host and manage your site: no, the work is done. Two small things help, though. First, have a click around your site when you get a moment. A new version of PHP can very occasionally disagree with older code, so if anything looks or behaves oddly, let us know at [email protected]. Second, if colleagues ask whether your site is safe, feel free to point them at this post.
If you run other websites outside our management, or arrange your own hosting, ask that host to confirm the PHP fix is actually installed, not just scheduled. Malwarebytes has sensible advice on what to ask. One important wrinkle: PHP 8.1 and older are end of life and will not receive a fix at all, so anything still running those versions needs upgrading to a supported version, not just patching. We’re happy to advise on sites we don’t manage; just ask.
The protection already around your site
A week like this is a good moment to recap the layers that sit around a Square Eye-managed site all year round.
Both of our hosting partners run hardened, managed platforms: isolated hosting environments, enterprise-grade firewalls and DDoS protection in front of every site, regular backups, and security patching handled by their own engineers, which is exactly the machinery that turned this week’s fix around within hours. Kinsta is also rolling out Vulnerability Protection, a free service powered by the security firm Patchstack that automatically blocks attempts to exploit newly discovered WordPress, plugin and theme vulnerabilities, often before an official fix even exists.
On top of the hosting layer, most client sites run dedicated security software (typically Kadence Security or Wordfence), which protects the WordPress login, blocks brute-force attempts and watches for unexpected file changes. And our management tools monitor every site’s uptime, software versions and known vulnerabilities daily, which is how we could verify this week’s fix across the board rather than site by site.
If you’d like to go further
A few clients have asked this week what more can be done, so here are the two additions we’d actually recommend. Neither is urgent and neither is needed to be safe from this week’s flaw, which is already fixed.
- A security plugin, if your site doesn’t have one. Most of the sites we manage already run Kadence Security or Wordfence, but a few don’t. For those, we’d suggest adding one, with the paid tier (Kadence Security Pro or Wordfence Premium) for the stronger protections: two-factor authentication for logins, brute-force blocking and file-change detection. We can install and configure either.
- Independent security monitoring (£10 a month). We can add an external security tool which keeps an off-site record of activity on your site (logins, new users, file changes), runs its own scheduled malware scans, and alerts us automatically to anything unusual. Because the records live outside the site, an intruder can’t quietly edit them, and it means a question like “has anything happened to our site this week?” can be answered from evidence in minutes. This goes beyond the security plugin on your site, whose logs live on the site itself.
If either appeals, just drop us a line at [email protected] and we’ll sort it out. We certainly recommend the first; the second offers additional, but optional, features.
Questions?
Email us at [email protected]. We’ll keep updating this post as the story develops.
