The gap between a vulnerability being published and someone actually exploiting it is reported to be short. This article checks the published numbers, with sources and dates, and then walks through how to rethink a monthly batch-update routine. The aim is to give you material for calm planning, not to alarm.
The numbers first (as of 2026-10-31)
Patchstack’s “State of WordPress Security in 2026” (page updated 2026-02-25) states:
- The weighted median time to first exploit, weighted by observed activity, is 5 hours
- About half of high-impact vulnerabilities are exploited within 24 hours
- 46% of vulnerabilities did not receive a developer fix in time for public disclosure
Source: Patchstack, State of WordPress Security in 2026
Three cautions when reading this:
- The 5-hour figure is a median over the vulnerabilities that were heavily exploited, weighted by activity. It is not an average of every vulnerability, and most are not hit this quickly
- Each research firm counts differently. Secondary write-ups cite different cutoffs, such as about 20% within 6 hours or a bit under 40% within 12 hours. Treat the result as an order of magnitude (hours to a day), not a single exact number
- The figure cannot tell you whether the plugins on your own site are among the targeted ones
Why a short window matters
When a fix is released, comparing the old and new versions can reveal what was changed. Automated attempts tend to rise after publication for that reason.
The weak point of a monthly batch routine is the gap:
| Routine | Longest gap between publication and applying the fix |
|---|---|
| Monthly batch | about 30 days |
| Weekly | about 7 days |
| Check on the day an advisory appears | 1 to 2 days |
If a vulnerability is exploited within hours, a 30-day gap leaves the site exposed for that whole time. This only matters when such a vulnerability appears in a plugin you actually run. The point is that you can choose how long the window is.
Exploitation before disclosure
Some flaws are exploited before they are published (zero-days). Updating quickly cannot help in that case. What you can do is limited but useful:
- Raise the priority of checking as soon as a fix appears
- Keep fewer plugins installed (see the inventory article)
- Keep a backup you know you can restore
Combine updating, owning less, and being able to roll back.
It does not mean “apply everything immediately”
Major WordPress releases can cause compatibility problems right after launch. As covered in earlier posts (waiting before a major update, failure patterns), waiting a little is often wise for feature releases. The two ideas do not conflict. Treat updates differently by type:
| Update type | Approach |
|---|---|
| Security fixes (especially unauthenticated, serious ones) | Check promptly, apply early |
| Routine bug fixes and minor updates | Apply in a weekly routine |
| Major releases with new features | Wait a little, verify, then apply |
To tell them apart, read the changelog for words like “security” or “vulnerability”, or look for an entry in a vulnerability database.
Turning it into a routine
You do not have to drop the monthly habit entirely. Make it two layers:
- Routine: once a week, review pending updates and apply the ordinary ones
- Ad hoc: decide where you will check advisories for the plugins you use, and act on the day one applies
Listing pending updates is read-only:
wp plugin list --update=available
wp theme list --update=available
wp core check-update
Take a backup before applying, and afterward confirm that the home page and key screens return HTTP 200.
Automatic updates
Automatic plugin updates shorten the gap, but a broken update is also applied automatically. Consider something like “security updates automatic, everything else manual”, depending on how important each site is. If you look after several sites, a per-site table of settings makes it easy to see the blast radius later.
Summary
- A published study reports a median of 5 hours to first exploit for heavily exploited vulnerabilities (Patchstack, updated 2026-02-25, checked 2026-10-31). It does not describe every vulnerability
- Numbers differ between studies. Read them as an order of magnitude
- You choose the length of the gap: turn “monthly” into a weekly routine plus ad hoc response
- Security updates early, major releases after a short wait
- Updating cannot stop exploitation before disclosure, so also own fewer plugins and keep restorable backups
One step for today: run wp plugin list --update=available and read the changelog of anything listed for security-related notes.