WordPress powers over 40% of the web, which makes it a frequent target. Interestingly, though, the platform itself is rarely where attacks succeed. The real vulnerability lies in the plugin ecosystem, and the standard advice most site owners follow doesn’t account for that gap.
The data from Patchstack’s State of WordPress Security report makes the source of risk clear: WordPress core is not the problem. Plugins are.
Yet most security guidance focuses on keeping WordPress updated, choosing a managed host, and installing a firewall. All measures that address the wrong layer of the stack.
The result is sites that appear hardened but remain exposed to the vulnerabilities that get exploited. Understanding where WordPress security breaks down, and why conventional advice leaves gaps, is the first step to closing them.
WordPress core vs. the plugin ecosystem
You might think WordPress is insecure. After all, it’s the platform everything runs on. But the real sources of risk are far less visible.
How secure is WordPress core?
According to Patchstack’s State of WordPress Security report linked earlier, WordPress core accounted for less than 1% of reported vulnerabilities. The remaining 99%+ came from plugins and themes.
That single figure reframes the question entirely. WordPress core is not the problem.
Why are plugins considered the biggest security risk in WordPress?
Plugins introduce third-party code directly into your site. Each one expands your attack surface, and the ecosystem is vast. There are over 61,000 plugins in the WordPress repository alone, with variable levels of maintenance and security scrutiny.
Patchstack’s data shows that plugins account for the overwhelming majority of WordPress vulnerabilities year-on-year. Themes contribute a smaller but non-trivial share. Core contributes almost nothing.
The standard response to this is “keep everything updated.” That advice isn’t wrong, but it’s incomplete. Updates only help when a fix exists. A significant share of disclosed vulnerabilities have no patch available at the point of disclosure, which means an updated site can still be vulnerable.
Supply chain attacks: When the update is the threat
The more serious problem is when the update itself is the attack vector.
In June and July 2025, two confirmed incidents demonstrated this risk.
On 27 June 2025, Groundhogg confirmed that malware had been distributed to paying customers through its own official plugin update system. This wasn’t a third-party breach or a compromised download mirror. Malicious code reached users through the legitimate update channel.
Two weeks later, Gravity Forms was targeted. A critical vulnerability allowed for remote code execution (RCE) and was actively exploited in the wild before a patch could be issued. With over one million active installations, the exploit left a massive number of sites exposed to total takeover.
Why paying for a plugin doesn’t mean paying for security
A common assumption is that premium plugins carry less risk. The data does not support this.
Patchstack’s report found that 76% of vulnerabilities in premium plugin components were exploitable at the point of disclosure. Across all vulnerabilities, paid and free, 46% had no fix available when they were made public.
Paying for a plugin buys features and support. It does not buy a guarantee of timely security response.
How WordPress sites get compromised
Having a vulnerability and being exploited are different things. Most vulnerabilities are discovered and disclosed before attackers act on them. The window between disclosure and patching is where most compromises happen.
WordPress sites are not uniquely easy to hack. They are common targets because the platform is ubiquitous, which means the return on developing exploits is higher.
XSS, SQL injection, and CSRF explained
According to the OWASP Top 10, broken access control is the most exploited vulnerability class. XSS gets more attention in general coverage, but it ranks lower in actual exploitation.
Cross-site scripting (XSS) lets an attacker inject malicious scripts into pages viewed by other users. In WordPress, this frequently appears in plugins that display user-submitted content without properly sanitising it. A comment field or a contact form can all become entry points if the handling code is flawed.
SQL injection targets the database directly. A vulnerable plugin might pass unvalidated input into a database query, allowing an attacker to read, modify, or delete data. Plugins that handle search functionality or custom queries are common sources of this vulnerability.
Cross-site request forgery (CSRF) tricks an authenticated user into unknowingly submitting a request. If a WordPress admin visits a malicious page while logged in, that page can trigger actions on their site without their knowledge, provided the targeted functionality lacks proper token verification.
Brute force attacks and why XML-RPC amplifies them
Brute force attacks target login credentials through repeated attempts. WordPress’s /wp-login.php endpoint is a standard target. At scale, these attacks are largely automated and can generate significant server load even when they fail.
XML-RPC makes this considerably worse. The system.multicall method allows multiple commands to be bundled into a single request. An attacker can test hundreds of password combinations in one HTTP request rather than one at a time, multiplying the efficiency of a brute force campaign while reducing its network footprint.
REST API, WP-Cron, and default feature risks
Not every default feature carries the same level of risk, and conflating them leads to unnecessary hardening that can break functionality.
The REST API can expose usernames at the /wp-json/wp/v2/users endpoint. While this helps attackers build a target list for brute force, it doesn’t grant access on its own.
XML-RPC carries real risk because it allows multicall attacks, letting an attacker try hundreds of passwords in a single request. Beyond brute-force amplification, it enables DDoS amplification via pingback functionality, where your site can be weaponised to flood another one.
Disabling XML-RPC is a straightforward mitigation with minimal functional cost for most sites.
WP-Cron is different. It is frequently listed as a security concern, but it is not a meaningful attack surface. It runs scheduled tasks triggered by site visits rather than a real system cron, which creates performance issues on high-traffic sites but not security ones. Disabling it for performance reasons is reasonable. Disabling it for security reasons is not.
User roles and privilege escalation
WordPress ships with five default roles:
- Subscriber
- Contributor
- Author
- Editor
- Administrator
The risk isn’t in the roles themselves but in how they are assigned and maintained.
Privilege escalation attacks exploit broken access control flaws in plugins or themes to elevate a lower-privileged account to Administrator.
This can happen without any credential compromise. A subscriber-level account can become an administrator if a vulnerable plugin fails to properly verify role permissions before executing sensitive actions.
Overly broad Editor/Admin access and lingering inactive accounts amplify the impact and likelihood of privilege escalation.
Why standard security advice leaves gaps
Most WordPress security guidance converges on the same recommendations: keep everything updated, use a reputable host, pick a strong password, and install a security plugin.
None of that is bad advice. It’s just insufficient on its own, and understanding why requires looking at what each measure covers.
We’ve published a more detailed guide on WordPress hardening that you may also want to check out.
Why your hosting provider may not fully protect you from plugin exploits
Managed WordPress hosts offer genuine security value. Server-level firewalls, DDoS mitigation, and infrastructure hardening are real protections — but they operate primarily at the network layer, where context about WordPress itself is limited.
Most WordPress-specific attacks don’t look like attacks at the network level. A request exploiting a broken access control flaw in a plugin arrives as a legitimate HTTP request. It uses the correct port, follows the correct protocol, and targets a real endpoint. The vulnerability isn’t in the request’s shape — it’s in the plugin’s failure to verify whether the user should be allowed to perform that action.
Some premium hosts run WordPress-aware web application firewalls with virtual patching for known plugin vulnerabilities, and these can catch a meaningful share of attacks. But coverage varies widely between providers, and even the best host-level WAFs work from generalised rulesets rather than the specific configuration of your site.
Application-layer threats are best addressed with application-layer defences. Security tooling that operates within WordPress — whether a dedicated plugin or a WordPress-aware WAF sitting in front of the site — can inspect requests in context, check them against known vulnerability signatures, and evaluate whether the behaviour is consistent with legitimate use of your installed plugins and themes.
The most resilient setups combine both: infrastructure protection from your host and application-aware defences closer to WordPress itself.
Why updating alone isn’t enough
Updates are the correct response to a disclosed vulnerability, but only when a patch exists. As noted earlier, data shows that 46% of vulnerabilities are disclosed without a fix available. During that window, an updated site remains exposed.
There is also the supply chain problem covered above. If the update itself contains malicious code, updating promptly makes things worse, not better.
Keeping plugins updated is necessary. It is not sufficient.
Why small sites are still targeted
Small sites aren’t targeted more because of what they contain, but because they’re plentiful and often under-maintained.
Automated scanning tools probe millions of WordPress installations continuously, looking for known vulnerable plugin versions. The size of the site is irrelevant to that process. A small business site running an outdated plugin is as exploitable as a large one running the same version.
Compromised small sites are used for spam distribution, hosting phishing pages, and participating in botnets. The attacker’s goal is rarely to steal data from that specific site. The site is just infrastructure.
What the “Not Secure” warning means
If your browser shows a “Not Secure” warning on your WordPress site, the cause is almost certainly a missing or misconfigured SSL certificate, rather than a security breach or a plugin vulnerability.
The warning indicates that the connection between the visitor’s browser and the server isn’t encrypted over HTTPS. It says nothing about whether the site has been compromised or whether vulnerabilities are present.
Fixing it means installing an SSL certificate and ensuring all traffic is redirected to HTTPS. Most hosts provide this at no cost via Let’s Encrypt.
It’s worth resolving, but it is just a configuration issue, not a sign that something has gone wrong.
How ShieldPRO closes each gap
Each vulnerability we’ve covered so far represents a documented attack pattern with a corresponding defensive gap. ShieldPRO is built around closing those specific gaps at the layer where they actually exist.
Application-layer protection that hosting WAFs miss
ShieldPRO’s WordPress-specific Web Application Firewall (WAF) operates at the WordPress application layer.
Unlike a hosting firewall, it inspects requests with full awareness of WordPress context: the current user’s role, the plugin being called, and whether the request pattern matches known exploit signatures.
This is what makes it effective against the plugin-based attacks that hosting firewalls miss. A request exploiting a broken access control flaw looks legitimate at the network level. At the application level, ShieldPRO can identify and block it.
For DDoS mitigation and broader network-layer protection, Cloudflare is a strong complement. ShieldPRO and Cloudflare address different layers and work well together.
Real-time plugin vulnerability detection
The 46% unpatched-at-disclosure figure means that reactive updating is not a complete strategy. ShieldPRO’s Plugin & Theme Guard addresses the gap between disclosure and patch availability.
It scans installed plugins and themes against a continuously updated vulnerability database and can automatically upgrade components when a fix becomes available.
For paid plugins, premium scanning extends this coverage to supported commercial plugins, which are otherwise harder to monitor systematically.
This doesn’t eliminate supply chain risk entirely, but it significantly reduces the window of exposure for known vulnerabilities and flags anomalies that warrant investigation.
Login and credential attack prevention
ShieldPRO addresses brute force and privilege escalation through a set of targeted controls rather than a single blunt measure:
- silentCAPTCHA challenges bots without presenting visible puzzles to real users, reducing automated login attempts without friction.
- Two-factor authentication adds a credential layer that makes stolen passwords insufficient on their own.
- XML-RPC can be disabled in a single click, removing the system.multicall amplification vector covered earlier.
- Security Admin adds a separate PIN requirement before ShieldPRO’s own settings can be modified. This prevents an attacker who gains WordPress admin access from simply disabling the plugin’s protections.
Automated risk management without configuration overhead
Two features address the scenarios where prevention fails.
MAL{ai} uses machine learning to detect unknown PHP malware. Signature-based scanning misses novel threats by definition. MAL{ai} identifies suspicious code patterns that lack known signatures, providing a layer of detection that remains effective against new attack variants.
ShieldBACKUPS provides automated off-site backups. If a site is compromised despite other controls, a clean backup stored separately from the hosting environment is what makes recovery possible without starting from scratch.
Protect your WordPress site today
The risks we covered in this article are well-documented and actively exploited. Plugin vulnerabilities, unpatched disclosures, supply chain attacks, and application-layer exploits are the current threat landscape for WordPress sites of every size.
Standard hardening measures are a foundation, just the start. Closing the remaining gaps requires protection that operates at the right layer, monitors the right signals, and responds without waiting for manual intervention.
ShieldPRO is built to do exactly that. Check it out today and explore how each protection maps to the threats covered here.
