One number should change how you run client sites. The average time between a WordPress vulnerability being disclosed and automated exploit attempts appearing against it has dropped from roughly seventy-two hours to under six.
That is not a trend to adapt to next year. It is the difference between a patching policy that works and one that does not.
Why it moved
Attack tooling got cheap and fast. Scanners identify vulnerable installations within minutes of a disclosure being published and the exploitation follows immediately behind. Brute force volume has climbed sharply as well, up around forty-five percent since early 2025 on some counts, driven by botnets that no longer need a person to tune them. Roughly one breach in six now involves an automated component somewhere in the chain.
The asymmetry is the whole problem. Disclosure is a public act. The same advisory telling you to patch tells everybody else precisely where to look. That was always true. What changed is how fast the second group can act.
Splitting your updates in two
Plenty of agencies batch updates, monthly if diligent and quarterly if not, because updates break things and batching means dealing with that less often. Under a seventy-two hour window that was a reasonable trade. Under six hours it is not.
What replaces it is not "update everything immediately", which swaps one risk for another. It is separating the two kinds of update and treating them differently. Security releases get applied straight away, automatically where you can, because the chance of a security patch breaking a site is real but much smaller than the chance of not applying it. Feature updates keep whatever cautious staging-and-testing cadence you already run.
And anything you cannot patch quickly, a heavily customised plugin or an abandoned dependency, is not a thing to manage. It is a liability to remove, and it should be on a roadmap with a date against it.
The harder half
Direct vulnerabilities are at least visible. The nastier category is a compromised update to a legitimate plugin, where malicious code is injected upstream and propagates to every site that updates. Automatic updates, your best defence against the first problem, are the delivery mechanism for the second.
There is no clean resolution to that tension. There are things that help. Run fewer plugins, because every one is a trust relationship you are maintaining. Prefer projects with a visible security process and a real disclosure policy. Keep off-site backups you have actually tested restoring from, because when prevention fails the recovery path is the only thing that matters.
The honest summary is that most compromised WordPress sites were not taken by anything sophisticated. A known vulnerability with an available patch sat unapplied for weeks. The attacking side has got dramatically better at finding those sites. The defence has not changed at all.
