You Patch WordPress Weekly. Attackers Can Act in Five Hours
Five hours. That is the activity-weighted median time from disclosure to first exploit that Patchstack recorded in 2025 for the WordPress vulnerabilities attackers targeted most heavily (Patchstack, State of WordPress Security in 2026).
If your agency checks updates weekly, or even every few days, that creates an uncomfortable gap. For the vulnerabilities that attract the most attention, attacks can start long before your next maintenance window.
That does not mean every WordPress vulnerability is an emergency. Most are not exploited that quickly. The challenge is knowing which ones cannot wait.
This article covers what the latest data shows, what happened with a recent critical WordPress flaw, and how agencies can decide when to update immediately, when to test first, and what to do when a patch is not yet practical.
Key takeaways
- The most heavily targeted WordPress vulnerabilities are often attacked within hours. Across the high-impact group Patchstack analysed, roughly half were exploited within 24 hours.
- A published fix can help attackers understand what changed, so disclosure and exploitation can happen very close together.
- Agencies need a triage process, not a policy of treating every update as urgent.
- When an update needs testing, client approval, or no developer fix exists yet, virtual patching can reduce the exposure window until the underlying software is updated. It depends on a protection rule existing for that vulnerability.
How fast are WordPress vulnerabilities exploited?
Patchstack's 2026 whitepaper looked at the vulnerabilities responsible for roughly 95% of the exploitation activity it observed for vulnerabilities published in 2025.
For that heavily targeted group:
- approximately half of high-impact vulnerabilities were exploited within 24 hours;
- after weighting vulnerabilities by the amount of exploitation activity observed, the median time to the first exploit was five hours.
The two figures measure different things. The 24-hour figure is the share of high-impact vulnerabilities that had been exploited. The five-hour figure gives more weight to the vulnerabilities that attracted the most attack activity.
The practical lesson is simpler than the statistics: when attackers decide a vulnerability is worth targeting, an agency may have hours rather than days to respond.
The volume is why triage matters. Patchstack counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025. Some 91% were in plugins, 9% were in themes and only 6 were in WordPress core. Of the total, 1,966 (17%) had a high severity score, meaning they were likely to be exploited in automated mass-scale attacks.
Plenty of vulnerabilities never see widespread exploitation. The job is to identify the small number that deserve an emergency response.
How fast was CVE-2026-87902 exploited?
WordPress disclosed and patched CVE-2026-87902 on 22 September 2026, according to the WordPress security advisory and the CVE record.
The flaw affected page-template resolution in WordPress core. Under particular theme and server conditions, an unauthenticated attacker could make WordPress include a local PHP file of their choosing, which could lead to remote code execution.
SecurityWeek reported a CVSS score of 9.2. WordPress released version 7.1.2 and backported the fix to maintained branches as far back as 4.7.
For an agency, the underlying template code matters less than the timeline:
- 22 September: WordPress publishes the fix.
- Within hours: Patchstack identifies the first exploitation attempts.
- By 23 September: the early reconnaissance activity escalates to active compromises, according to SecurityWeek.
The vulnerability did not affect every WordPress site. Specific theme and server conditions had to be present.
But attackers did not need to know which sites were vulnerable before trying. Once an exploit method existed, testing large numbers of sites could be automated. A flaw that affects only part of your client estate can still demand a very fast response.
Why can attacks appear so quickly after disclosure?
Two things make the window small.
The patch can reveal the problem
When a security update is published, researchers, defenders and attackers can compare the old code with the fixed code. That can make the vulnerable behaviour much easier to identify.
A security release starts two clocks at once:
- defenders can begin patching;
- attackers can begin working out how to exploit the flaw.
For CVE-2026-87902, Aviatrix reported that threat actors began exploiting the flaw within hours of the patches being released on 22 September.
Exploitation can be automated
Once someone has a working request, script or scanning rule, trying it against another website costs very little. An attacker does not have to choose your client's site. They can send the same request to large numbers of WordPress sites and concentrate on whichever respond in a useful way.
Why do update cycles and attack cycles clash for agencies?
Most agencies cannot safely install every WordPress update the moment it appears. A plugin update might affect a checkout, booking flow, membership site or custom integration. Clients may require testing or approval. Some updates need a developer involved.
That makes scheduled maintenance sensible. The problem is that attackers do not work to your maintenance schedule. A weekly update process gives you consistency, but it does not guarantee that a serious vulnerability can wait until Friday. So keep the testing, and add a separate fast lane for the vulnerabilities that genuinely cannot wait.
How should an agency decide what to patch first?
A good triage process should answer three questions quickly.
1. Can the vulnerability be attacked without logging in?
An unauthenticated vulnerability is generally more exposed, because the attacker does not first need a customer, editor or administrator account. That does not automatically make it critical, but it should move the issue up your list.
2. What happens if the attack succeeds?
Pay particular attention to vulnerabilities that can lead to:
- remote code execution;
- authentication bypass;
- arbitrary file upload;
- SQL injection;
- privilege escalation;
- exposure or modification of sensitive data.
The potential impact matters as much as the technical severity score.
3. Does the affected configuration exist on your sites?
A critical advisory may only apply when a particular plugin version, theme, PHP configuration or feature is present. This is why an up-to-date inventory matters. When an advisory appears, you should be able to identify affected client sites quickly rather than logging into every WordPress installation one by one.
What response model should an agency use?
| Priority | Typical situation | Response |
|---|---|---|
| Urgent | No login needed, serious impact, exploitation already reported | Act within hours. Update immediately where safe, or apply a temporary mitigation while testing |
| High | Serious vulnerability, but no active exploitation reported | Test promptly and update within days |
| Routine | Lower impact or difficult-to-meet attack conditions | Include in the normal maintenance cycle |
This does not replace reading the actual advisory. It gives your team a consistent starting point.
The most important operational step is to agree the emergency process with clients before you need it. If your maintenance agreement allows urgent security fixes without waiting for normal sign-off, say so clearly. Arguing over who has authority to act while an exploit is already circulating wastes valuable time.
What if you cannot update immediately?
Sometimes an urgent update still cannot go straight into production. You may need to test compatibility. The client may need to approve a change. A developer may not have released a fix yet.
That is the gap virtual patching is designed to help with.
A virtual patch does not change the vulnerable WordPress plugin, theme or core code. It applies a protection rule that blocks known exploit behaviour before the request reaches the vulnerable code. That gives an agency another option: protect first, test properly, then install the real update.
Virtual patching is no substitute for updating, because the vulnerable code still needs to be fixed. It also depends on a protection rule existing for the vulnerability in question, so coverage can lag a brand-new disclosure. What it can do is shorten the period in which a publicly understood vulnerability leaves the site exposed.
We explain the approach in more detail in our guide to how WordPress virtual patching works.
For Layershift customers using Plesk, WP Guardian provides virtual patching for supported WordPress vulnerabilities. Server-level tools such as Imunify360 add another layer through firewall, web protection and malware detection. Agencies running many client sites can see how these fit together on the Agency Optimised VPS page.
These layers solve different parts of the problem. Patchstack reported that only 26% of total attacks were blocked by traditional hosting defences, which is why application-level protection such as virtual patching sits alongside server security rather than being replaced by it. None of these layers removes the need for WordPress maintenance.
What if there is no developer patch yet?
This is another reason an update-only security policy is incomplete.
Patchstack reported that 46% of vulnerabilities disclosed in 2025 had no developer fix available when they became public.
Depending on the vulnerability, your options may include:
- disabling the affected plugin or feature;
- restricting access to the vulnerable functionality;
- applying a firewall or virtual patching rule;
- replacing the affected component;
- monitoring closely until a vendor patch is available.
The right choice depends on the site and the vulnerability. What matters is having an option other than waiting.
Do you need to check for compromise after updating?
For a serious vulnerability that was already being exploited, yes.
Installing the security update closes the vulnerability. It does not automatically remove a web shell, rogue administrator account or malicious file that an attacker added beforehand.
After patching a high-risk vulnerability, consider checking for:
- unexpected PHP files;
- unknown WordPress administrator accounts;
- modified WordPress core files;
- suspicious scheduled tasks;
- unusual recent file changes or security alerts.
The faster exploitation starts, the more this matters. A site may have been exposed before your team even saw the advisory.
What should agencies change?
You do not need to turn every WordPress update into an emergency. You need to recognise the few that are.
For an agency managing multiple client sites, that means:
- keep an accurate inventory of WordPress core, themes and plugins;
- monitor credible vulnerability advisories;
- define what makes an issue urgent;
- agree emergency update authority with clients;
- have a temporary mitigation option for updates that cannot be installed immediately;
- check for compromise when a serious vulnerability was actively exploited before you patched it.
Scheduled maintenance still matters. It just should not be your only response to a vulnerability that attackers may start exploiting within hours.
Not sure how your sites would hold up if an advisory landed on a Friday afternoon? Talk to us and we will walk through your current protection with you.
Running WordPress for several clients? See how the Agency Optimised VPS bundles virtual patching, malware protection and monitoring.
Frequently asked questions
How quickly are WordPress vulnerabilities exploited?
It varies widely. Patchstack found that among the vulnerabilities attracting the most exploitation activity, the activity-weighted median time to the first observed exploit was five hours. Approximately half of the high-impact vulnerabilities in the analysed group were exploited within 24 hours. That does not mean every WordPress vulnerability is attacked within hours.
Does every WordPress security update need to be installed immediately?
No. The urgency depends on factors such as whether authentication is required, what an attacker can achieve, whether exploitation has already been observed and whether the site meets the vulnerable conditions.
Why can attackers exploit a vulnerability so soon after a fix is released?
A public patch can reveal which code changed. Attackers can compare vulnerable and fixed versions and use the security-sensitive change to help develop automated exploit requests or scanning tools.
Is it safe to wait a few days before updating a client site?
Sometimes. Lower-risk vulnerabilities may be suitable for normal testing and maintenance. A serious unauthenticated vulnerability that is already being exploited may require an emergency response.
What can an agency do if an update cannot be installed yet?
Depending on the vulnerability, you may be able to disable the affected component, restrict the vulnerable feature, use a firewall rule or apply virtual patching while the permanent update is tested.
Does virtual patching replace WordPress updates?
No. Virtual patching can block known exploit behaviour while the underlying code remains vulnerable. The proper software update should still be installed once it is available and has been tested.
Does updating remove an existing compromise?
No. An update closes the vulnerability but does not automatically remove malicious files, accounts or other changes an attacker may already have made.
