Five Hours

Patchstack put the median gap between a WordPress vulnerability going public and being exploited at scale at about five hours. Most maintenance plans run monthly. I want to do that arithmetic on the page, because it changes what you should be asking maintenance to do.

The sums

A monthly update cycle means that, on average, a flaw disclosed today gets patched on your site in about fifteen days. Against a five-hour exploitation window, you are roughly seventy times too slow. Move to weekly and you are still about seventeen times too slow. Daily, and you are still losing.

The July core flaws made the point more sharply. Thirteen minutes between the first probe and the first exploitation attempt. There is no maintenance schedule that wins that race, and there is no team you could hire that would.

It gets worse before it gets better. Patchstack found that 46% of vulnerabilities had no fix available on the day they went public. So even if you could patch instantly, for nearly half of them there would be nothing to apply.

Why "patch faster" is the wrong conclusion

This is the point where security articles usually tell you to tighten your update process, and I do not think that is where the evidence points.

You cannot win on speed. Nobody can. What you can change is how often you are in the race at all, and that is a question about how much software your website is running.

Of the 11,334 WordPress vulnerabilities Patchstack logged in 2025, 91% were in plugins and 9% in themes. Six were in core. The surface is the add-ons. Every plugin is another thing that can be disclosed on a Tuesday afternoon while you are doing something else.

So the useful question is not "how quickly do we patch?" but "how many things are we exposed to in the first place?" A site running forty plugins is in the race forty times as often as a site running six. That is the whole argument, and it is arithmetic rather than opinion.

What helps

Fewer components. Every plugin should be earning its place (The Seven Plugins You Need Before You’ve Even Started), and the test is what your site would stop doing if you removed it. If the answer is "nothing much", that is not a feature, it is exposure.

Native features over bolted-on ones, where the platform offers them. A thing your platform does itself is maintained by the people who maintain the platform.

Automatic core updates left switched on. Given the five-hour figure, the case for turning them off has more or less evaporated. If you have them off because an update broke something once, the fix is to test updates on a private copy of the site first, not to leave a permanently open window.

And somebody who notices. Not someone who runs updates on the first Monday of the month, but somebody who sees the advisory, knows whether it applies to your site, and can act on it the same day when it does. That is a different service to the one most maintenance plans describe.

The reframe

Maintenance is usually sold as diligence, a monthly tick against a list. The numbers say it should be sold as reduction, keeping the number of things that can go wrong as low as the site can stand.

Our own maintenance works on that assumption. We cannot win a five-hour race for you, and I would not claim otherwise. What we can do is make sure you are in far fewer of them.

If you have never counted what your site is running, that is the place to start and it costs nothing. Get in touch if you would like a hand going through it.