WordPress Vulnerability Triage for Agencies: Building a Patch SLA That Beats the Exploit Window

Ninety minutes, not thirty days

On 17 July 2026 the WordPress project shipped 7.0.2, described in the release note as fixing "one critical and one high severity security issue", with 6.9.5 and 6.8.6 backports alongside it. The two issues were a SQL injection in the author__not_in parameter of WP_Query (CVE-2026-60137) and a REST API batch route confusion bug (CVE-2026-63030). Chained, they gave an unauthenticated attacker remote code execution against a default install. The WordPress security team enabled forced updates through the auto-update system for affected versions.

Patchstack, which was watching the traffic, recorded the first real exploitation attempts about ninety minutes after the release, and more than 65,000 attempts from over 1,500 unique IP addresses in the days that followed. Four days later attackers had moved to delivery techniques designed to slip past the first wave of filtering rules.

That last row is worth sitting with. When CISA added the pair to the Known Exploited Vulnerabilities catalogue on 21 July, the remediation date it attached to the remote code execution half was 24 July, three days later, under Binding Operational Directive 26-04. US federal agencies do not usually move faster than a competent web agency. If they were given three days, a monthly patch cycle is not a defensible answer.

This was not an unlucky month. Patchstack's State of WordPress Security in 2026, published in February 2026, counted 11,334 new vulnerabilities in the ecosystem during 2025, a 42% rise on the year before. 91% of them were in plugins and 9% in themes. Only six were in core, all low risk, which makes July's core chain the exception that proves where the everyday risk actually lives: in the thirty or forty third-party components sitting on each client site.

Why a severity score is not a decision

The obvious way to triage is to sort by CVSS score and work down the list. It does not survive contact with WordPress, and the July chain is the clearest demonstration you will find. Both CVEs carry two separate CVSS v3.1 base scores in the National Vulnerability Database, submitted by different scoring sources, and they disagree in opposite directions on the two halves of the same exploit.

An agency that had filtered its alert feed at "critical only" using the first source would have patched one half of the chain and ignored the other. An agency using the second source would have done the reverse. Neither number was wrong by the rules of the CVSS specification. They were just scoring different things, in isolation, which is exactly what CVSS is designed to do and exactly what attackers do not do.

There are three structural reasons scores mislead in the WordPress ecosystem.

• WordPress privilege levels do not map onto CVSS cleanly. "Privileges required: low" means something very different on a site with open customer registration than on a five-person brochure site where the only accounts are staff. The same score describes an open door and a locked one.
• Scores rank components, not chains. A medium-severity SQL injection that needs a plugin to pass untrusted input is unremarkable on its own. Bolted to a route confusion bug that supplies exactly that input, it becomes remote code execution.
• The distribution is flat. Most disclosures land in the medium band, including many that are not realistically exploitable and some that are being mass-attacked. Sorting by score leaves you with a long, undifferentiated list and no signal about where to start.

The practical fix is not to discard severity. It is to demote it from decision to input, and to add the input it is missing: what an attacker actually needs in order to reach the vulnerable code on this specific client site.

A triage matrix you can actually run

Every incoming vulnerability gets four questions, in this order. They take about ninety seconds per disclosure once the habit is formed, and they produce a response class rather than an opinion.

1. Is it being exploited right now? Check the CISA KEV catalogue and your vulnerability feed's exploitation flag. A yes ends the assessment: it is P0. Nothing else in this list can downgrade it.
2. What does an attacker need in order to reach it? Unauthenticated, or a specific role? If a role, does this site hand that role to strangers? Open registration, WooCommerce customer accounts, membership plugins, and comment subscriptions all turn "requires subscriber" into "requires nothing".
3. Is the vulnerable code path live on the site? An installed but deactivated plugin, or a feature the client never enabled, is a lower-priority cleanup rather than an emergency. Be honest here, because deactivated plugin files are still reachable by direct request in some configurations.
4. What does this site actually hold? A checkout with stored customer records, a members area, or a site that is the client's entire sales pipeline all justify moving a class up. A brochure site with a contact form does not.

The clocks matter more than the labels. Pick numbers you can meet with the staff you have, write them into the care plan, and then measure yourself against them. A four hour P0 target that you hit is worth far more than a one hour target you quietly miss. If four hours is not achievable at 2am on a Sunday, say so and price a service that is, or set the target at the start of the next business day and be honest that this is the trade.

Three practical notes. First, P0 work skips the change-approval queue by design, so the care plan needs a standing authorisation for emergency security work, otherwise the fastest path is blocked by an email nobody reads until Monday. Second, the same batching discipline that protects developer focus and care plan margins still applies to P2 and P3: those belong in the weekly run, not in a stream of interruptions. Third, the reason a P0 is survivable at all is that the update itself is reversible. Snapshotting before the change and verifying pages afterwards with automatic rollback is what makes it reasonable to push an urgent update at speed instead of waiting for a window in which someone can watch it by hand.

The 46% problem: when there is no patch

Here is the part almost no maintenance guide addresses. Patchstack found that 46% of vulnerabilities did not have a patch available at the time of disclosure. Roughly one in four was still unpatched thirty days later, and a long tail of them will never be fixed at all because the component has been abandoned.

An update-driven workflow has nothing to say about almost half of its own inbox. If your process is "wait for the update, apply the update", then for those disclosures your process is "wait", and the waiting is invisible to you and to the client. A triage policy needs an explicit branch for this, with five options and a bias toward the ones at the top.

Two cautions on virtual patching, because it is often sold as the universal answer. Patchstack's 2026 testing found that conventional hosting-level defences blocked only a fraction of WordPress-specific vulnerability attacks in their sample, and the single most exploited category, broken access control, is precisely the category that generic rules struggle with. A request that exploits a missing capability check looks identical to a legitimate one at the network layer. Treat a virtual patch as a bridge with an expiry date, not a destination.

The blind spot WordPress will not show you

When a plugin is closed or removed from the WordPress.org directory, whether for a security issue, a guideline violation, or at the author's request, site owners are not told. The plugin simply stops receiving updates. As Patchstack puts it in its analysis of repository access restrictions and plugin closures, "WordPress core shows closed plugins just as an up-to-date plugin (as they have no new updates available)", and there is no indication on the Site Health screen either.

Read that again in the context of a care plan. Your dashboard shows a green tick. The client's monthly report shows a green tick. The component has been pulled from the directory for a security issue and will never be patched. Nothing in the standard WordPress toolchain will ever tell you, and this is not a rare edge case: closures happen in waves, sometimes dozens or hundreds of plugins in a single day when a shared author account is compromised or a vendor is banned.

The good news is that the WordPress.org API answers this question directly, and it is trivial to automate. Ask the plugin information endpoint about a slug. An open plugin returns its metadata. A closed one returns an error object with a machine-readable reason.

# A plugin that is still in the directory returns normal metadata.
curl -s https://api.wordpress.org/plugins/info/1.0/akismet.json

# A closed plugin returns a structured closure record instead:
curl -s https://api.wordpress.org/plugins/info/1.0/wp-config-file-editor.json

{
  "error": "closed",
  "name": "WP Config File Editor",
  "slug": "wp-config-file-editor",
  "description": "This plugin has been closed as of July 22, 2021 and is not available for download. Reason: Security Issue.",
  "closed": true,
  "closed_date": "2021-07-22",
  "reason": "security-issue",
  "reason_text": "Security Issue"
}

The reason field is the useful part. security-issue means treat every install as an active finding today, regardless of whether a CVE was ever published for it. author-request is a much softer signal, worth a scheduled replacement rather than an emergency. Run this across the distinct plugin slugs on your estate on a schedule, and cross-check anything that returns a closure or a 404 against whether that component was installed from the directory in the first place, since premium and bespoke plugins were never there and will always return "not found".

The first 48 hours: a runbook

When a P0 lands, the failure mode is not usually ignorance. It is five people improvising in a group chat while nobody is sure who is covering which client. Write the sequence down once, before you need it.

1. Confirm and classify (0 to 15 minutes). Read the advisory itself, not the summary in a newsletter. Note the affected version range, the fixed version, the privilege required, and whether exploitation is confirmed. Assign the response class.
2. Scope the estate (15 to 30 minutes). Which sites run the affected component, at which version? This number, produced quickly and accurately, is the difference between a controlled response and a panic. Sort the affected list by exposure, not alphabetically.
3. Name one owner. One person runs the response and holds the list. Everyone else takes assigned sites. Silence about who is doing what is how two people patch the same site and nobody patches the fifth.
4. Fix, starting with the most exposed (30 minutes onward). Snapshot, apply, verify the key pages, move on. If there is no patch, run the no-patch decision above and record which option you chose per site, because they will not all be the same.
5. Verify, do not assume. Re-query the estate for the fixed version. A queued update, a failed cron, a file-permission problem, or a plugin pinned by a hosting rule will all leave a site behind, and the update log will happily say the job ran.
6. Assume breach on anything that was exposed and exploited. For the July core chain, defenders were advised to inspect sites regardless of patch status. Check for administrator accounts nobody recognises, users created in the exposure window, unexpected plugins, PHP files under the uploads directory, unfamiliar scheduled tasks, and modified core files. Patching an already-compromised site locks the attacker's backdoor in behind the fix. An activity log that records who created which user and when turns that from a forensic exercise into a filter.
7. Tell the client, once, in writing (within 24 hours). What happened, whether their site was affected, what you did, and what you found. Send it after the fix for a P0, not before. A client who hears about a WordPress vulnerability from the news before hearing from you has learned something about your care plan that no monthly report will undo.
8. Write the retrospective while it is fresh (within 48 hours). How long did detection take? Which sites were slowest and why? Which step was manual that should not have been? Put it in the internal knowledge base as an agency runbook the next person can follow, not in a chat thread that scrolls away.

One process detail is worth extracting. Steps 4 and 6 generate real, unplanned, billable-or-not work, and without somewhere to put it that work silently comes out of your margin. Logging emergency security work as tracked requests with time against them is what makes the difference between a care plan that absorbs an incident and one that quietly loses money on it. It also gives you the data for the next pricing conversation.

What to put in the care plan

Most WordPress care plans promise "security updates" and "monitoring" and leave every meaningful term undefined. That is comfortable right up until the week it is not. Four clauses, written plainly, are worth more than a page of reassurance.

• Response times by class, not one number. State the P0, P1, P2, and P3 clocks and what puts a vulnerability into each. A single "we patch within 48 hours" promise is simultaneously too slow for the things that matter and needlessly strict for the things that do not.
• Standing authorisation for emergency security work. Give yourself the explicit right to apply security fixes, disable a compromised component, or take a feature offline without waiting for approval, with a commitment to notify within a stated window afterwards.
• What happens when there is no patch. Say that removal, replacement, or restriction may be required, that it may change site behaviour, and how it is estimated and billed if it is substantial. This is the clause that prevents the awkward conversation in which the client hears "we deleted your booking plugin" for the first time after the fact.
• The boundary. Name what you do not cover: components the client installs themselves, custom code you did not write, abandoned premium plugins the client refuses to replace, and hosting-layer security. Then say what happens when a client declines a recommended removal. Getting that refusal in writing protects both sides.

If you are revisiting the plan anyway, this is a natural moment to look at whether the price matches the obligation, since a genuine P0 commitment is an out-of-hours commitment. The broader maintenance stack behind a modern care plan is the context for that conversation, and the agency SOP that surrounds it is where these clauses turn into a repeatable procedure rather than good intentions.

Proving the work happened

Vulnerability response is the least visible valuable work an agency does. Handled well, the client experiences nothing at all: no downtime, no defacement, no call from their payment processor. The natural consequence is that it looks like nothing happened, which is exactly how a care plan ends up being renegotiated down to "you just click update once a month".

The fix is not to overstate the drama. It is to make the record legible. Four things are worth surfacing to the client, in their own portal, without being asked.

• What was found and when. The vulnerability, the affected component, and the date it appeared on their site's record.
• What was decided. Patched, removed, replaced, restricted, or accepted with a review date. The decisions that were not "install the update" are the ones that demonstrate judgement.
• How long it took. Time from disclosure to resolution, against the target you promised. This is the single most persuasive number in a renewal conversation, and almost nobody reports it.
• What was verified afterwards. Pages checked, rollbacks avoided, and any breach checks performed.

That record is the same one your team needs internally, which is the point: a branded client portal should be a view onto work that already exists, not a second place to retype it. The argument for that is the same one behind why silence costs agencies retention: clients do not churn because you failed, they churn because they could not see that you succeeded.

Common questions

Sources and further reading

• WordPress 7.0.2 security release announcement and the ongoing WordPress security release feed
• Patchstack, State of WordPress Security in 2026 (published February 2026), the source for the 11,334 vulnerability count, the 42% year-on-year rise, the 91% plugin share, and the 46% unpatched-at-disclosure figure
• Patchstack, on the ninety-minute weaponisation of the July 2026 core chain
• CISA Known Exploited Vulnerabilities catalogue and Binding Operational Directive 26-04
• NVD entry for CVE-2026-63030 and NVD entry for CVE-2026-60137
• FIRST, CVSS v4.0 specification document
• Vulnerability feeds worth subscribing to: Patchstack database, Wordfence Intelligence, and WPScan
• WordPress core handbook: reporting security vulnerabilities

Product references

• WordPress updates, rollback, page verification, and vulnerability monitoring
• Activity log across every connected site
• Change requests, SLA targets, and time tracking
• Branded client portal and reporting
• Internal agency runbooks and client documentation
• Platform security and WordPress connector authentication