Two critical flaws in PHP went public this week, with working exploits and a nickname to match: PHP2Shell. WordPress sites went into patch queues, a handful of public services switched themselves off as a precaution, and hosting companies everywhere had a busy Wednesday. No Miaigi site had to do any of it, and this post explains why in plain English: what the bug actually was, who it touched, and how the way we build keeps this class of problem out of range.
The PHP vulnerability, explained
PHP is the server-side language most of the web's familiar tools are built on. WordPress runs on it, and so do Drupal, Joomla and MediaWiki, the software behind Wikipedia. When PHP itself has a hole, everything standing on it inherits the worry.
On 20 and 21 October 2026, two such holes were made public: CVE-2026-109618 and CVE-2026-109619. Both scored 9.2 out of 10 for severity. They allow what's called pre-authentication remote code execution: an attacker runs their own code on the server without an account or a password, which is the most damaging class of web bug there is.
Two details made this one unusual. First, the flaw sits in PHP's engine, below the application layer, so it didn't matter how carefully a site's own code had been written. Even a minimal PHP script on an affected version was in scope, and that scope covers versions going back to PHP 5.4, over a decade of releases. Second, researchers, including Wiz, used frontier AI models to build working exploits out of memory flaws that had sat undisturbed for years, then demonstrated them against WordPress, Drupal and Joomla. PHP's maintainers released fixes on 21 October 2026, and the patch has been rolling out since.
Who was affected
Mostly WordPress, by sheer weight. Wiz's own headline puts PHP behind about 70% of the internet, and Computer Weekly cites a count of roughly 24 million PHP sites by BuiltWith's tally. The long-standing tracker count for WordPress alone is around 40% of the entire web. When a language under that much of the internet wobbles, the blast radius is wide.
"Affected" meant one precise thing: running an unpatched PHP version that the internet could reach. The fixes published on 21 October cover PHP 8.2 and newer, so sites on older versions have had to wait for backported patches from their distributions or hosts. The gap between publication and complete patching is where this week's risk lived, and for the long tail of older, unmanaged sites it will outlive this news cycle.
Several organisations chose to go dark as a precaution rather than sit unpatched, which is the sensible order of operations. Finland temporarily shut its government public web services. The Dutch cyber-security agency's site went offline. Wikipedia took some of its systems offline until they could be patched. None of that was proof of compromise. It was prudence, and it tells you how seriously the people who run serious infrastructure took it.
Why Miaigi sites weren't in the firing line
What we won't say first: that sites we build can never be attacked. No honest builder earns that sentence. What we can say precisely is that PHP isn't in our stack, so the component that made this week's bug dangerous isn't something our sites run.
Here's the build. Every Miaigi site is Next.js with React, delivered through Microsoft Azure Static Web Apps. Pages are generated ahead of time and served as files from the edge. There is no PHP interpreter sitting behind them for an exploit to reach, and there is no WordPress. There are no plugins either, which matters because plugins are where much of the day-to-day risk of CMS websites actually comes from: a third-party extension nobody has updated.
The parts of a site that do need to run code, such as the contact form, run on our own Node-based service rather than a PHP mail script. Fewer moving pieces, and no shared interpreter, is a smaller surface for any future bug. That is a deliberate design decision, not a lucky absence.
We checked anyway, because claiming and verifying are different things. On 22 October, a day after the patch landed, we probed eight live client sites ourselves. None served WordPress at wp-login.php, and none exposed the PHP signatures that show up by default in most server response headers. There is no PHP anywhere in what we build or host. That's our own audit across properties we control, not a certification, but it matches the architecture: the vulnerable component simply isn't there.
What this means for our clients
Practically speaking, nothing. No patch to apply, no downtime to plan for, no decision to make. For our care-plan clients, nothing changes: hosting, monitoring, backups and updates keep running on a stack that never contained the vulnerable part.
That calm is the point. The work that makes a site hard to hit happens before an incident, in choices about architecture, not in emergency patching afterwards. It's a fair bit of what we mean by digital architecture, and it's why weeks like this one stay quiet on our side.
Still on WordPress? A friendly option
If your business site runs WordPress, three things are worth ten minutes this week. Ask your host which PHP version you're on and whether the 21 October fix has been applied. Update your plugins and remove the ones you don't use. And if your host can't answer the first question quickly, that's a finding in itself.
If you'd rather not manage that treadmill, we're happy to help. We'll run a free safety check on your site and give you a straight answer in plain English, whatever it turns out to be. If you're curious about a website that doesn't need this kind of patching at all, we'll show you what one looks like and what it costs. Get in touch. No hard sell: this is a chat, not a campaign.
Sources
- Wiz Research, "PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet", 21 October 2026
- ENISA, "Joint statement on critical PHP vulnerabilities", with the European Commission, CERT-EU, Europol EC3 and the CSIRTs network, 21 October 2026
- Computer Weekly, "Critical PHP flaws puts millions of websites at risk of takeover", 21 October 2026
- The Cyber Express, "PHP2Shell patch rush takes Wikipedia, gov sites offline", 22 October 2026
- W3Techs, content management usage statistics, accessed 22 October 2026
