The real WordPress risk is not core: it is plugins, themes and lack of process

Summary

Why WordPress agencies should stop blaming core by default and focus on inventory, plugins, themes, prioritization and operational response.

It is convenient to say that WordPress is the problem. It is also incomplete.

For an agency managing dozens of sites, the real risk is usually not a clean, up-to-date WordPress core installation. The risk appears in the daily mix of plugins, themes, premium components, client exceptions, old installs, delayed updates and the absence of a visible process for deciding what needs attention first.

That distinction matters because it changes the client conversation. If the diagnosis is “WordPress is insecure”, the answer sounds like a platform migration. If the diagnosis is “we do not have enough visibility or process around the real surface of each site”, the answer becomes much more practical: inventory, prioritization, alerts, hardening, evidence and response.

WordPress core is not perfect, but it is not the most chaotic layer

WordPress.org describes a security process for core, responsible disclosure, reviews, security releases and coordination with hosts and ecosystem providers. It also makes a point agencies should repeat more often: security is not about eliminating every possible risk, but reducing risk with reasonable controls.

That does not mean core can be ignored. WordPress, PHP, the server and the rest of the stack all need maintenance. But when an agency manages 25, 50 or 100 sites, the hard part is rarely knowing that core should stay updated. The hard part is knowing which extension and theme combinations exist across the portfolio, what they mean, and which action matters today.

The practical risk shifts to plugins, themes and premium components

Patchstack’s State of WordPress Security in 2026 report says 11,334 new vulnerabilities were found in the WordPress ecosystem in 2025, a 42% increase over 2024. The same report says 91% of new vulnerabilities were found in plugins and 9% in themes; six vulnerabilities were reported in WordPress core, described as low-priority issues.

The takeaway is not “plugins are bad”. Plugins are one of the reasons WordPress works so well for real businesses. The correct takeaway is that a WordPress portfolio is not protected by looking only at core. Every plugin and theme adds code, permissions, dependencies, maintainers, update cycles and possible process failure.

Patchstack also highlights an uncomfortable agency problem: premium components. In its analysis, premium or freemium components represented a meaningful share of valid reports, and vulnerabilities found in that group had a high proportion of real-world exploitability. Paying for a plugin does not automatically make it a safer component.

The problem is not just patching. It is arriving in time

Updating is necessary, but it is not enough as the only strategy. Patchstack says 46% of vulnerabilities did not receive a developer fix in time for public disclosure. It also reports that, for heavily exploited high-impact vulnerabilities observed in 2025, the weighted median time to mass exploitation was 5 hours.

Wordfence’s Quarterly WordPress Threat Intelligence Report for Q1 2026 listed 2,738 vulnerabilities during the quarter and noted that 747 remained unpatched at the end of the period. The same report mentions 16.0 billion brute force attacks blocked during Q1 2026. These numbers should not become panic. They should become operations.

When the time between disclosure, exploitation and internal decision-making can be measured in hours, an old spreadsheet is not enough. Neither is waiting for a client to report that something feels wrong. The agency needs to know which sites exist, what they run, where suspicious activity appears, which basic controls are missing and who needs to act.

Lack of process turns a small flaw into a portfolio problem

A vulnerable plugin on one site may be a technical ticket. The same pattern repeated across thirty sites is an operational and commercial issue.

The problem grows when nobody can answer simple questions quickly:

Which sites use the affected component?
Which version is installed on each one?
Which sites are critical for the client or revenue?
Which sites show recent suspicious activity?
Which sites have incomplete hardening?
What was done, when, and with what evidence?

Without that process, teams work from memory, urgency or noise. They update what is loudest, not necessarily what carries the most risk. They answer tickets, but struggle to prove control. And when the client asks whether they are covered, the answer becomes too vague.

An agency needs a decision model, not just an update list

A simple operating model can change a lot:

1. Live inventory

It is not enough to know how many sites the agency manages. You need plugins, themes, versions, hardening status, recent activity and business criticality. The inventory should reflect today’s reality, not a snapshot from three months ago.

2. Risk-based prioritization

CISA recommends using its Known Exploited Vulnerabilities Catalog as an input for prioritizing vulnerabilities exploited in the wild. The same mindset helps in WordPress: not every update has the same weight, not every site has the same exposure and not every client has the same tolerance for interruption.

3. Documented response

Security without evidence is hard to sell and hard to defend. An agency should be able to explain what was detected, what was reviewed, what changed, what remains pending and what recommendation was given to the client.

4. Honest communication

Promising “secure sites” is a trap. Promising visibility, review windows, prioritization criteria and verifiable reporting is more credible. It is also easier to deliver.

Where Vulnity fits

Vulnity should not be presented as a magic tool that automatically detects every CVE in plugins, themes or core. That is not the right promise.

The honest promise is different: helping agencies and WordPress teams keep a centralized operational security view across their sites, receive alerts, review suspicious activity, track hardening signals, block malicious IPs when applicable and turn security work into client-ready reporting.

That changes the agency’s position. Instead of reacting site by site, it can manage the portfolio as a system. Instead of selling “maintenance included”, it can explain an observable security process. Instead of improvising every incident, it can work with context.

WordPress core should not be the automatic scapegoat in every security conversation. The real problem usually sits in the extended surface: plugins, themes, integrations, exceptions, old installs and decisions nobody sees until something breaks.

For an agency, the question is not whether WordPress can be secure. The question is whether the agency can prove what it has, what changed, which risk it prioritized and what action it took when a signal appeared.

CTA: If you manage multiple WordPress sites and still rely on spreadsheets, team memory or scattered manual checks, Vulnity is built to give you a centralized view of operational security. Try it to understand which sites need attention before the next ticket arrives too late.

Sources

About Vulnity

Keeping WordPress secure requires continuous operational visibility. Vulnity helps monitor suspicious activity, alert on relevant changes, and keep response evidence in one place.