Security field notes · 22 October 2026
On Tuesday night, Brisbane time, details of two critical flaws in PHP leaked onto the internet before anyone could fix them. Researchers are calling it PHP2Shell. PHP is the language underneath WordPress and most of the websites Australian businesses run on. The official fix arrived at about 11.30 pm on Wednesday. That left a full business day where everyone knew and nobody could patch. We didn’t wait.
What PHP2Shell is, in plain English
PHP2Shell is two flaws, CVE-2026-109618 and CVE-2026-109619, in PHP itself. Not in a plugin. Not in a theme. Not in WordPress. In the engine underneath all of them. The PHP project rated both 9.2 out of 10 for severity and said every PHP installation that serves web pages is at risk.
“Remote code execution” sounds like jargon, so here is what it means for an owner. A stranger sends your website a request, and your server runs their instructions. No password. No login. In the worst case PHP described, the attack fires before any of your website’s own code has started. That includes your security plugin, which is still waiting for WordPress to load.
Source: PHP security advisory, 21 October 2026
The part that should get your attention is how it was found. The researchers at Wiz say the underlying weaknesses had been sitting in PHP for a very long time, and that frontier AI models are what made turning them into a working attack practical. Those same tools are available to everyone else. Expect more of this, and expect it faster.
What it costs you if it lands
Nobody breaks into a small business website for the thrill of it. They break in because your website is a useful tool. Once someone can run code on your server, the bill looks like this:
- Your site quietly hosts someone else’s phishing pages, malware or spam, under your name and your domain.
- Anything the site touches is exposed. Researchers also showed a way to read the server’s memory, which can hold passwords, API keys and other secrets.
- Search engines and email providers start treating you as a threat. Enquiries drop and you don’t know why.
- The clean-up costs days of someone’s time, and if customer data was involved, it stops being an IT problem and becomes a board problem.
What we did, and when
- Tuesday night: researchers confirmed the leak was real. PHP brought its emergency release forward to midnight Brisbane time on Wednesday.
- Wednesday 21 October: every site we host had protection in place before the official fix existed.
- About 11.30 pm Wednesday: PHP shipped the fix.
- Since then: the patched release is going onto every server we look after, and we are reading the logs back to the hour the details leaked.
I’m not going to publish how. We don’t publish how anything we host is defended, and a step-by-step for the first day of a live vulnerability is a gift to exactly the wrong people.
What I will say is that it was a long day, and we work AI first. Models did the legwork across every server. People made every call that mattered. That is the whole point of the arrangement: the machine is fast, and a person who has seen this before decides whether it’s right.
The pattern I keep seeing
Thirty-five years of this, and the pattern does not change. The damage happens in the gap between the moment attackers know and the moment the fix is actually applied. A leak just fires the starting gun early.
Most hosting is built to wait. Wait for the vendor. Wait for a maintenance window. Wait for someone to read an email. Each wait sounds reasonable on its own. Added together it’s days, and serious flaws are now attacked within hours of going public.
Then there is the long tail. Plenty of sites run on old PHP, on cheap hosting nobody has logged into for years. They will not be patched this week, and some will never be. The UK’s National Cyber Security Centre went as far as telling organisations to consider taking systems offline if they can’t be fixed or mitigated quickly. That is not a sentence government agencies write lightly.
Four questions to ask your host this week
If someone else looks after your website, send them these. You want a date and a name for each answer.
- Which version of PHP is our site running? The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35, or newer. If the answer is 8.1 or older, the PHP project is not shipping a fix for it.
- When exactly was it patched? “We’re on it” is not a date.
- Did you do anything before the fix came out? The leak was public a full day before the patch.
- Who is checking the logs back to 20 October, and what happens if they find something? Patching closes the door. It does not tell you whether someone already walked through it.
The question to ask this week
“What version of PHP is our website running, and when was it patched?”
If you get a shrug, that is your answer too.
Next step
Not sure where your site stands? A Security Audit gives you a straight answer in one day, for $1,000 inc GST. If you think something is already wrong, incident response starts from $700 inc GST. And if you would rather this was somebody else’s long day, that is what our managed hosting and monthly maintenance are for.