November 2, 2026 By: JK Tech
You probably saw the headlines and thought, “Not my problem, I don’t even know what PHP is.”
Fair. But there’s a decent chance your company’s website, your favourite online store, or the portal you log into every Monday runs on it. So let’s talk about what actually happened, because the story is better than the headlines made it sound, and the lesson is one every team can use.
The plan that fell apart
The PHP team had found two nasty flaws. Nasty as in an attacker could take over a website without even logging in. So they did what careful people do. They prepared the fixes quietly, picked a release date, and planned to ship everything at once.
Then the secret got out.
Details leaked on 20 October, and the team pulled the release forward to the 21st. A proof-of-concept video even got published by accident. If you’ve ever hit “reply all” on the wrong email, you know that feeling, except this was a lot bigger.
The internet wasted no time
Here’s the part that made people sit up. Amazon spotted an attempted attack on 17 October, four days before the flaws were announced. Whether it would have worked on a real system isn’t clear, but it tells you something. Somebody was already knocking on doors.
After the announcement, things got loud. Cloudflare saw attempts jump from tens of thousands in the first 45 minutes to millions by the next morning. CISA, the US cybersecurity agency, told organisations to update immediately.
The trap most people walked into
Now for the plot twist. When we hear “security update,” most of us think of our website’s plugins and themes. Update those, done. Not this time.
The flaws were in PHP itself, so updating plugins and themes changed nothing. Only a fixed version of PHP did. It’s like repainting a room while the leak is inside the wall. Looks great. Still leaking.
So what do we take from this?
First, a fix existing and a fix being installed are two different things. The patch was ready on day one. Plenty of websites needed a human to actually do something.
Second, speed matters more than we’d like. The gap between “announced” and “attacked” is now hours, not weeks.
And third, never assume somebody else has it covered. In most companies, nobody is quite sure whose job it is to update the server. That’s usually how problems sit around for months.
What you can do this week
Start with one small question to whoever looks after your website: “Which PHP version are we running?”
You want to hear 8.2.35, 8.3.36, 8.4.27 or 8.5.12, or something newer. If you hear anything older, or a long silence, you’ve found your to-do list. Older versions need a supported upgrade or a backport from the provider.
While you’re at it, ask your hosting provider for a written yes that they’ve patched, and ask your tech team to check for odd activity since mid-October. Then give one person ownership of updates, by name. Once someone’s name is attached, things get done.
The takeaway
Every technology has a bad week eventually. This was PHP’s. What separates the calm teams from the scrambling ones isn’t luck. It’s knowing what they run, knowing who owns it, and being able to act before the news has even finished loading.
