I’ve never known security warnings to arrive at this pace.
Across WordPress core and PHP, it feels as though barely a week passes without a serious issue to check. Keeping up has become a much bigger part of the job, and it’s changed how I approach website security.
The critical PHP security release on 21 October 2026 brought that into focus. The flaws were in software that websites, including WordPress, run on. Updating WordPress itself wouldn’t fix them.
For a business owner, that might seem like a small technical detail. It raises a simple question: who is looking after everything your website depends on?
Website security is changing as old flaws come to light
The PHP Foundation says AI-assisted research is bringing in more reports. Some expose real flaws. Others repeat known findings, can’t be reproduced, or turn out to be wrong.
More reports don’t mean software has suddenly become less secure. Some flaws have been present for years. Closer study is bringing them into view.
WordPress has also issued several security releases in recent weeks. Each one needs checking against the sites I manage.
Finding a flaw is useful. Someone still has to work out which sites it affects, act on it, and check the result.
A fix arrived before the planned release
The PHP release also showed what can happen when the parties involved fall out of step.
According to the PHP Foundation’s account, Chainguard published software builds containing the fix early. That happened at 07:41 UTC on 21 October, more than six hours before the coordinated public release. The Foundation describes this as a breach of the agreed embargo.
Attackers could then study the patched software while many users were still waiting for their updates. By comparing the old and fixed versions, someone could work backwards to find the flaw.
The Foundation says it hadn’t found a working exploit among the public examples its team checked before the release. The early builds gave attackers a chance to study the fix. That alone doesn’t prove they used it in a successful attack.
I find that troubling. You can have someone watching for updates and still be left waiting for your host to supply them. Getting a fix written is only part of the work. The people who need it must have a fair chance to put it in place.
Knowing what you’re looking after comes first
I’ve been putting more effort into keeping a full record of the software, servers and services I look after. Alongside that, I’ve been building up my use of active monitoring and alerts.
When a warning arrives, I want to know which systems could be at risk and who needs to act. Does the work sit with me, a hosting provider, or someone else?
That saves having to piece together the setup every time something happens. It also helps find gaps between what an owner assumes is covered and what someone is looking after.
Monitoring needs judgement as well. An alert helps when someone can make sense of it and act on it. A growing pile of unread warnings gives you very little protection.
I’ve had to develop new skills
I’ve been investing in specialist cybersecurity models and learning how to coordinate multiple AI agents during security work.
That includes finding possible flaws, planning patches and managing fixes. Different agents can look at separate parts of a problem, with someone directing the work and checking their findings.
Managing that process takes practice. I need to set clear limits and know enough about the system to challenge the output. That matters even more when a live website is involved.
AI can sound certain and still be wrong. I need evidence that a reported flaw is real, and a way to check that a proposed fix works.
I’ve applied for access to OpenAI’s Daybreak programme as part of that work. I want to get better at finding and fixing weaknesses in the systems I look after.
What this means for website owners
You shouldn’t need to follow every PHP warning or understand the details of a WordPress security flaw.
You should be able to ask who monitors the software your website relies on and how urgent issues are handled. You should also know who checks that a fix has taken effect.
For me, this has meant learning more about the systems I manage and the tools I use to check them. When something needs attention, I want to know where to look and have a clear way to act.
Those responsibilities are part of ongoing WordPress maintenance. They also inform decisions during WordPress development, from custom code to choices about software.
If you’re not sure who handles them for your business, send me the details. We’d start by working out what’s being looked after and where the gaps are.
Published .