WordPress auto-updates: how many hours you are exposed

Your auto-updates are on. That is not the same as being patched

There is a gap between the moment a security fix exists and the moment your site runs it. Auto-updates do not remove that gap. They just mean nobody is watching it.

The gap is measurable now, because two different clocks were measured in 2026. On one side, attacks against a freshly patched WordPress core started roughly 90 minutes after the release. On the other, the plugin directory holds new releases for hours before your site is even told they exist. Both numbers were measured by the same WordPress security vendor, on its own sensors and its own sampling of the directory. What nobody spells out is what the pair means for the person who owns the site.

How fast does an exploit actually arrive?

Faster than any update mechanism WordPress has. For heavily targeted vulnerabilities the weighted median time to first exploit is five hours, and roughly half of high-impact vulnerabilities are exploited within 24 hours of disclosure, according to that vendor's annual report on WordPress security, published in 2026 and covering 2025 data.

The core release of 7.0.2 in 2026 shows the shape of it in one incident. The fix landed in the public trunk about 90 minutes before the release was even tagged, which is itself a disclosure: anyone watching commits could read the patch and work out the bug. Then, by the vendor's account of what its sensors saw, the first real exploitation attempts arrived roughly 90 minutes after 7.0.2 was released - three hours after the fix was committed.

It went on to block more than 65,000 attempts from more than 1,500 unique IP addresses. That spread matters more than the raw count. The busiest single network accounted for 6.45% of the traffic and the top ten together for about 22%, which means this was not one botnet with one owner. It was the whole industry of automated scanning, turning over the same lock at once.

Two vulnerabilities were involved: CVE-2026-60137, a SQL injection through WP_Query, affecting 6.8 through 7.0.1, and CVE-2026-63030, a route confusion in the REST batch endpoint, affecting 6.9 through 7.0.1. Both were fixed in 7.0.2, 6.9.5 and 6.8.6.

Why does the patch wait before it reaches you?

Because since 5 June 2026 the WordPress.org directory deliberately holds new plugin and theme releases before distributing them, across roughly 78,000 plugins and themes. The measure is called Protect The Shire, and the hold is real and measured.

The same vendor tracked the actual durations: a median hold of 24.2 to 24.5 hours through 7-15 July, dropping to 6.6 to 6.8 hours from 16 July, a shift that happened in a single day across hundreds of releases.

During the observed window, 81 releases that patched disclosed CVEs went through the delay, across 79 different plugins with roughly 9.9 million installs between them. Thirty of those fixes were rated CVSS 7.0 or higher. Nine were 9.0 or higher, including one rated 10.0.

So the sequence for a plugin vulnerability, in order: the fix is published, the directory holds it, attackers read the disclosure, your site is still running the old version - and for the vulnerabilities attackers actually chase, the five-hour median has already elapsed.

One honest qualifier, from the same people who published the measurements: they looked for exploitation happening inside those hold windows between 7 July and the time of writing, and found none. The window is a risk that has been measured, not a body count.

Does the "Update Now" button skip the queue?

No, and this is the part worth knowing before the next security headline. The delay does not live in the auto-update feature. It lives in the update-check API - the mechanism that tells your site an update exists at all. Both routes depend on it: the automatic update and the manual button are gated by the same clock, which is the point the vendor's write-up of the hold makes explicitly.

Your dashboard shows you the version you already have and stays quiet about the one that was released this morning. There is no indicator, no "held" state, no countdown. The screen looks exactly like a site with nothing to update.

The one route that is not gated is installing the release yourself: download the plugin's zip from the developer and upload it. That is the entire workaround, and it is worth doing exactly when it matters - a critical vulnerability in a plugin you actually run - rather than as a habit. Note what you are also stepping around, though: the hold exists to catch poisoned updates, so take the zip from the vendor's own site or your paid account only. Never from a mirror, a "nulled" bundle or whatever a search result offers.

Isn't the delay there for a reason?

Yes, and any article telling you the hold is simply a mistake is worth distrusting. It exists to catch supply-chain attacks, where the danger is not an unpatched bug but a poisoned update.

It has already worked at least once in public. In July 2026 a backdoor was pushed into version 10.8.7 of Advanced Responsive Video Embedder, a plugin with roughly 20,000 installs. Rated CVSS 9.8, it read a token from a request parameter, compared it against a hardcoded hash, and logged the sender in as an administrator - no credentials needed. A security vendor flagged it less than two hours after it appeared, and WordPress.org closed the plugin for downloads - inside the hold window.

That is the trade honestly stated. Holding releases protects everyone from poisoned updates and exposes everyone to known bugs for longer. It is a defensible choice. What the dashboard never says is that the choice was made, or how long your side of it lasts.

Doesn't the host patch this for me?

Less than most owners assume. The same annual report puts a number on how much conventional protection actually stops: only 12% of WordPress-specific vulnerability attacks were blocked in one study, and 26% of total attacks in a broader one. The vendor sells virtual patching, so read those rates with that in mind - but the direction is not controversial. A firewall in front of the site is not a substitute for the fixed version of the code behind it.

Managed hosts do patch, and some patch quickly. What is hard to establish is how quickly, because published service levels for applying a security release are not easy to find - we could not locate documented windows for the major managed hosts, which is not the same as proving none exist. If your host has one, it is a fair question to ask them directly: how long after a WordPress security release does my site have it, and how would I know?

Ask it now rather than during an incident. The answer also tells you whether anyone there is watching at all.

How exposed are you, exactly?

Mostly through plugins, not through WordPress itself. Of the 11,334 new vulnerabilities found across the ecosystem in 2025 - a 42% rise over 2024 - 91% were in plugins and 9% in themes. Core accounted for six.

That changes where attention belongs. Core auto-updates are the part of this system that works best, and core has the fewest problems. The exposure sits in the twenty or thirty plugins accumulated over the years, each on its own release schedule, each behind the same hold.

One more number worth holding onto: 46% of vulnerabilities had no patch at all at the time they were disclosed. For those, no update mechanism of any speed would have helped.

What can you do about it today?

Nothing exotic, and none of it takes a developer:

1. Write down what you actually run. Plugins, themes, versions. Most owners cannot name theirs, which makes every security headline unanswerable - you cannot tell whether it applies to you.
2. Cut the list. A deactivated plugin still ships code to your server. Every plugin you delete is a release schedule you no longer depend on.
3. Check that auto-updates are actually on, plugin by plugin. This is the step most owners skip, because they assume it is the default. It is not: WordPress core has updated itself since 2013, but plugin and theme auto-updates arrived only in version 5.5 and are off until someone switches each one on. A site can sit for years with "auto-updates" that were never enabled for the plugins that carry 91% of the risk. Late updates beat absent ones.
4. For a critical vulnerability in a plugin you run, install the zip yourself. This is the only way to move faster than the hold, and now you know why the dashboard alone will not tell you it is available.
5. Know who looks after the site. If nobody has logged in for a year, the updates are not the largest problem.

Two things not to do. Do not measure safety by the absence of an update notification, because during the hold that is exactly what an out-of-date site looks like. And do not assume a security plugin closes the gap: it may block some traffic, at the rates quoted above, but the vulnerable code is still running.

What it costs when the window closes on you

More than the update would have. Recovery is priced as its own service, and priced by how fast you need it: Sucuri sells platform plans at $229 a year with a 30-hour cleanup commitment, $339 for 12 hours and $549 for six, while Wordfence prices Care at $590 a year and Response at $1,250, both with incident response included. Those are vendor list prices checked in August 2026 and quoted in US dollars, not a market average. Advertised one-off cleanups from smaller firms ran from roughly $125 to $799 in the same check, with serious e-commerce incidents quoted higher - again advertised prices, not a survey of what people paid.

Urgency is priced separately on top. One WordPress repair shop lists the identical job at $99 within 24 hours, $149 within 12 and $299 within 4 - a threefold spread from response time alone.

And restoring a backup often does not end it. If the backup predates the intrusion you lose everything since; if it postdates it you restore the backdoor along with the content. Either way the entry route stays open unless the vulnerable component is updated, which is the same job you were putting off. The pattern shows up verbatim in plugin support threads:

My website was hacked some weeks ago, through the loop hole in your plugin. I restored to a earlier malware free version of my website, deleted your plugin and guess what....I JUST GOT HACKED AGAIN THIS WEEK!!!

• a site owner, WordPress.org support forum

Restoring and even deleting the plugin was not enough, because the way back in had already been left somewhere else.

This is the same failure as an automation that stops firing quietly: the dashboard looks calm while the business pays for it. If your site is already behaving strangely - unfamiliar admin accounts, redirects your visitors see but you do not, pages in search results you never wrote - that is not an update problem any more, and what a fixed-price website repair covers is a different job from staying current. You can size it yourself before talking to anyone.

Sources

• One WordPress security vendor's 2026 annual report (median time to exploit, vulnerability counts, blocking rates), its account of the 7.0.2 exploitation timeline and its measurement of the directory hold - read on the vendor's own site in August 2026 and given without a name
• Website malware removal, Sucuri - list pricing, checked August 2026
• Pricing, Wordfence - Care and Response list pricing, checked August 2026
• The emergency-repair tiers were read on the shop's own page in August 2026 and are given without a name
• CVE-2026-18072, GitHub Advisory Database - the backdoored plugin release caught inside the hold window