A weekly plugin-update session used to feel like due diligence. Check the dashboard, click Update, move to the next client. That ritual assumed you had days between a public disclosure and a mass exploit. For the WordPress flaws attackers actually pile onto, that assumption is gone.

Patchstack’s State of WordPress Security in 2026 puts the weighted median time from disclosure to mass exploitation — for heavily targeted vulnerabilities — at five hours. About half of high-impact issues are exploited within 24 hours. Forty-six percent of vulnerabilities had no vendor patch at the moment they became public.

If your process is “keep plugins updated,” you are optimizing the wrong number. Volume of updates is not the same as reduction of exposure. The job is to know which connected sites have the affected component today, then decide what jumps the queue — including the cases where there is nothing to click.

What the five-hour figure actually means

It is not the average for every CVE in the ecosystem. Patchstack measured how fast heavily exploited vulnerabilities moved from public disclosure to mass exploitation, weighted by how intense that activity was. Low-severity issues on unused plugins are not in that five-hour bucket. The ones that are tend to be high-impact, automatable, and already in scanner feeds.

That still changes the agency calendar. A Friday maintenance window does not cover a Wednesday 11 a.m. disclosure. Neither does a monthly retainer that batches “all the updates” into one afternoon. By the time the newsletter roundup lands, the opportunistic scans have already run.

Patchstack also recorded 11,334 new WordPress-ecosystem vulnerabilities in 2025 — a 42% increase year on year — with 91% in plugins. More findings does not mean every finding deserves the same hour of your week. It means the filter has to get better, not louder.

AI speeds up weaponization. It does not replace known CVEs.

You will see a lot of posts this year about “AI-generated malware.” Treat most of them as trend wrapping. The mechanism that matters for portfolio work is narrower: once a flaw is public, writing a proof of concept and pointing a scanner at it is cheaper and faster than it used to be. Large language models are one accelerator of that loop. They are not a new class of infection that weekly updates magically stop.

Two adjacent AI stories are real and still the wrong call to action. Custom “vibe-coded” plugins that skip nonces and ship REST routes with open permission callbacks are a review problem, not an Update-button problem. Poisoned plugin releases — changelog says performance, shipped diff exfiltrates salts — are a reason to be more careful with blind auto-updates, not less. Neither is solved by telling clients to “stay on top of plugins.”

Why “update everything” fails the 46% case

If nearly half of disclosures arrive without a vendor fix, a process that only knows how to apply patches stalls on the days that matter most. The next actions are operational, not cosmetic:

  • Identify every site in the portfolio that runs the affected plugin, theme, or PHP/core combination — including inactive copies still on disk.
  • If a patch exists and the component is live on a revenue site, that issue jumps the queue ahead of tidy-up updates.
  • If no patch exists, disable the component, restrict access, or put a WAF/virtual-patch rule in front of it until a fix ships.
  • If the component is unused, remove it. Dormant code is still scanned.

That is triage. It is also why exploitability has to outrank “number of available updates” in any score you trust. WP Triage already weights known-exploited / KEV-style signals above slow-burn maintenance debt; the scoring methodology is public so you can see that bias.

A Monday morning that matches the clock

The workable agency loop looks like the one in how to triage WordPress client sites, compressed for the five-hour window:

  1. Sort the portfolio by risk, not by client name.
  2. Open Critical and At Risk sites first. Read the top three issues, not the full inventory.
  3. Patch or mitigate the actively exploitable item before the abandoned sidebar widget.
  4. Batch the same vulnerable plugin across clients in one session.
  5. Leave low-severity update noise for the weekly digest. Page the team only for critical vulns and sudden score drops.

Execution still happens in the tools you already use — Wordfence or a host WAF to block, MainWP, ManageWP, or WP Foundry to push updates, hosting panels to change PHP. Scoring does not replace those jobs. It answers the question they cannot: which site, which issue, in what order. See how that sits next to scanners and dashboards.

What WP Triage will and will not do

Connect the sites, and daily snapshots tell you which installs match a newly disclosed component version. A 0–100 score plus a ranked fix order is there so the next hour has a starting point. That is the product.

It will not block the exploit, clean malware, virtual-patch at the edge, or inspect custom plugin source for vibe-coded holes. If you need those, keep the WAF, the malware scanner, and a human review of anything you generated last weekend. Use WordPress risk scoring when the portfolio is too large to hold the exposure picture in your head.

Weekly updates are still hygiene. They are not a five-hour response plan. Rank first, then update — and have a move ready for the days there is no update at all.

Connect your WordPress sites, or start from the agency workflow if you already run a Monday triage list.