The Hidden Security Bill: Why 91% of WordPress Hacks Start With a Plugin
August 20, 2026 · The Valley Marketing Group
If your website runs on WordPress, the biggest threat to it almost certainly isn't WordPress itself. It's the plugins sitting on top of it. WordPress logged 11,334 new vulnerabilities in 2025 — a 42% jump over the year before — and 91% of them were found in plugins, not WordPress core. WordPress plugin security isn't a footnote in a broader WordPress hack story; for the overwhelming majority of service businesses running WordPress, it is the story. We spend a lot of our time at Valley moving local service businesses off WordPress entirely, and this is the single biggest reason why: not because WordPress is a bad platform, but because the ecosystem built around it has become one of the most reliably exploitable attack surfaces on the internet.
This isn't a hunch or a sales pitch dressed up as data. It's the conclusion we keep arriving at every time we audit a prospective client's site and find seven, twelve, sometimes twenty active plugins, most of them installed years ago by a different developer, most of them never updated, all of them sitting there as potential doors into the client's database, customer records, and Google rankings. We wrote our full breakdown of why we made this switch away from WordPress as our default build platform, and plugin security is the chapter of that story that deserves its own deep dive — because most business owners have no idea how exposed a "normal," well-maintained-looking WordPress site actually is.
The Scale of the Problem: 11,334 New Vulnerabilities in a Single Year
Let's start with the number that should stop any WordPress site owner mid-scroll: 11,334 new vulnerabilities were disclosed across the WordPress ecosystem in 2025, according to Colorlib's WordPress hacking statistics report. That's not a typo, and it's not a slow accumulation over a decade — it's a single year, and it's up 42% from the year before. The trend line is not flattening. It's accelerating.
A WordPress vulnerability is a flaw in code — core, a theme, or a plugin — that allows an attacker to do something the software was never designed to let them do: read data they shouldn't see, write data they shouldn't be able to write, or execute commands on the server itself. Every one of those 11,334 disclosures represents a specific, documented way an attacker could compromise a WordPress site running the affected code. And in 2026, the pace hasn't slowed — Webmastered reports that more than 250 new plugin vulnerabilities are now being disclosed every single week.
Put those two numbers side by side and the picture is unambiguous: WordPress plugin security isn't a niche IT concern for enterprise sites with custom code. It's a weekly, industry-wide flow of new exploitable holes, discovered faster than most site owners could ever hope to track, let alone patch.
Why This Is a Plugin Problem, Not a WordPress-Core Problem
Here's the detail that gets lost in most "WordPress is insecure" headlines, and it matters enormously for how you should think about your own site: WordPress core — the actual software maintained by the WordPress Foundation — is not where the danger lives. Of those 11,334 vulnerabilities disclosed in 2025, only 9% were found in themes. WordPress core itself accounted for just 6 vulnerabilities all year, and every single one of them was rated low priority.
Read that again, because it reframes the entire conversation. Core WordPress, the software that actually runs the CMS, is maintained by a large, well-resourced open-source team with a mature security review process. It is, by these numbers, remarkably solid. The problem isn't the house. It's the thousands of unlocked side doors that third-party developers have bolted onto it.
WordPress's entire value proposition is its plugin ecosystem — over 60,000 plugins in the official repository alone, built by tens of thousands of independent developers with wildly varying levels of security expertise, ongoing maintenance commitment, and incentive to keep patching a plugin they may have written five years ago and now barely think about. A plugin vulnerability is a security flaw introduced by that third-party code — code that was never reviewed with the same rigor as WordPress core, that often has direct access to your database, your user accounts, and your file system, and that in many cases is written and maintained by a single developer or a small team with no formal security process at all.
91% of 2025's vulnerabilities living in that layer isn't a coincidence. It's the predictable outcome of an architecture that outsources most of a site's actual functionality — forms, SEO tools, page builders, caching, e-commerce, security plugins themselves — to code nobody at WordPress ever vetted.
The Math of "Just a Few Plugins"
Most service-business WordPress sites we audit aren't running one or two plugins. They're running a form plugin, an SEO plugin, a page builder, a caching plugin, an image optimization plugin, a backup plugin, a security plugin (which is, itself, a plugin with its own vulnerability surface), a booking or scheduling plugin, and often two or three more nobody remembers installing. Each one is a separate codebase, a separate developer or team, a separate update cadence, and a separate potential entry point. Security researchers sometimes describe this as attack surface — the total sum of every point where an unauthorized user could try to get in. Every plugin you activate adds to that surface. It doesn't matter how well the rest of the site is built; the site's security is only as strong as its most poorly maintained plugin.
How These Attacks Actually Happen
It's worth being specific here, because "vulnerability" can sound abstract until you see how these actually get exploited. Webmastered's analysis of disclosed WordPress plugin vulnerabilities breaks the attack patterns into three dominant categories, and understanding them explains why this problem is so hard for a typical business owner to defend against.
Authentication Bypass (43% of vulnerabilities)
Authentication bypass is a flaw that lets an attacker skip the login process entirely — gaining admin-level access to a WordPress site without ever knowing a username or password. This is the largest single category of plugin vulnerability, and it's the most dangerous, because it doesn't require the attacker to guess a password, run a brute-force attack, or trick anyone into clicking a phishing link. The flaw is in the code itself: a broken permission check, a missing verification step, an endpoint that trusts data it shouldn't. Once bypassed, the attacker has the same control over the site as the site owner does — the ability to edit content, install new plugins, create new admin accounts, or redirect the entire site to somewhere else.
SQL Injection (18% of vulnerabilities)
SQL injection is an attack where malicious code is inserted into a data field — a form, a URL parameter, a search box — in a way that tricks the site's database into executing commands it was never meant to run. Depending on the flaw, this can let an attacker read every row in your database (customer names, emails, phone numbers, lead data, sometimes stored passwords), or in worse cases, modify or delete that data outright. For a local service business, this is the scenario where years of leads, customer contact information, and appointment history can disappear or leak in a single automated attack.
Stored Cross-Site Scripting / XSS (12% of vulnerabilities)
Stored XSS is a vulnerability that lets an attacker permanently plant malicious script code on your site — inside a comment, a form submission, a product listing — so that it runs automatically in the browser of every visitor (or every admin) who later loads that page. Once planted, it can steal admin session cookies, silently redirect visitors to scam or malware sites, or inject spam content and hidden links that tank your SEO and get your domain flagged by Google.
Together, these three categories account for 73% of all disclosed WordPress plugin vulnerabilities. None of them require the attacker to be a sophisticated, targeted adversary. Once a vulnerability like this is published, it gets automated — folded into scanning bots that crawl the entire internet looking for any site running the vulnerable plugin version, whether that site belongs to a Fortune 500 company or a two-truck plumbing outfit in Mesa. The bots don't care who you are. They care whether your plugin version matches the exploit.
The Patching Gap: Why "Just Keep It Updated" Isn't a Real Answer
The standard advice for WordPress security is simple to say and, it turns out, close to impossible to actually live up to: keep every plugin updated, every single time a patch ships. The data on how that advice plays out in practice is where the WordPress plugin security conversation gets genuinely alarming.
According to Webmastered's research, the median time from a vulnerability's public disclosure to its first real-world exploitation is just 5 hours. Five hours. Not five days, not five weeks — the gap most site owners assume they have to apply a patch before anyone notices barely exists. Automated scanning tools pick up newly disclosed vulnerabilities from public databases almost immediately and begin probing the internet for vulnerable sites within hours of disclosure, often before the average business owner has even seen a notification that an update is available.
It gets worse. 43% of new WordPress vulnerabilities require zero authentication to exploit — meaning an attacker doesn't need a stolen password, a compromised admin account, or any kind of insider access. They just need to find your site and know which plugin version you're running. And on the defense side: 23% of disclosed vulnerabilities had no patch available within 30 days of public disclosure. That means for nearly a quarter of these flaws, even a business owner who is diligently checking for updates every single day has nothing to update to — the vulnerability is public, attackers are already scanning for it, and there's no fix yet.
Perhaps the most telling number in the entire dataset: more than half of the plugin developers Patchstack reported vulnerabilities to did not patch before the vulnerability was officially, publicly disclosed. In other words, the responsible-disclosure process — where a security researcher privately warns a developer so they can fix the issue before it becomes public knowledge — is failing more often than it's succeeding. Developers are told about the hole in their own code and, more than half the time, the disclosure clock runs out before they've closed it.
This is the part that gets missed in most "just update your plugins" advice: updating isn't a guarantee of safety, because the update frequently doesn't exist yet when the exploitation window opens. You are, structurally, playing defense against a threat that can move faster than the people responsible for defending it.
What This Actually Costs a Service Business Owner
It's easy to read vulnerability statistics as an abstract IT problem. For a local service business — an HVAC company, a dental practice, a med spa, a roofing crew — a successful plugin exploit is not abstract at all. It's operational.
- Downtime. A compromised site often has to be taken offline entirely while it's cleaned, which means your phone number, your booking form, and your Google-indexed pages go dark during exactly the hours customers are trying to reach you.
- Reputation damage. If an attacker plants spam content, redirects, or malicious scripts on your site, visitors see it before you do. A customer landing on a hacked dental site — or worse, being silently redirected to a scam page — doesn't come back, and they don't recommend you either.
- Google blacklisting. Search engines actively scan for malware, injected spam links, and phishing redirects. Once Google flags a site as compromised, it can be pulled from search results and browsers will show visitors a full-page "This site may harm your computer" warning before they ever reach your homepage — erasing the SEO work you've spent months or years building.
- Cleanup cost and time. Removing a plugin-based compromise properly means auditing every file for injected code, resetting every credential, and verifying the vulnerability that let the attacker in is actually closed — not just patched on the surface. That's specialized work, and it's rarely fast.
- Data exposure. If the exploit reached your database — which SQL injection specifically targets — you may be looking at exposed customer names, emails, phone numbers, and lead history, with all the trust and, depending on what was stored, compliance implications that come with it.
None of this requires a business to be a specific target. The overwhelming majority of WordPress compromises are opportunistic — automated bots scanning millions of sites for a known vulnerable plugin version, with no idea or interest in who owns the site. Being small doesn't protect you. It just means nobody's watching closely enough to catch it fast.
Why "Better Plugin Hygiene" Isn't the Real Fix
The instinctive response to all of this is usually some version of: keep fewer plugins, update religiously, hire someone to manage it. We understand the appeal, but we don't think it holds up against the numbers above, for a simple reason — hygiene assumes the exploitation window is on your side. It isn't. A median 5-hour gap from disclosure to first exploit, combined with a 23% chance no patch exists within 30 days, means even an owner doing everything right is exposed by design, not by neglect.
There's also a structural issue that better habits can't solve: every plugin you keep is still third-party code with direct access to your database and file system, written by a developer whose security priorities you don't control and whose future maintenance commitment you can't guarantee. You can reduce the number of doors. You can't fully vet what's behind each one, and you can't force a plugin author to patch faster than an attacker can scan.
This is why our position at Valley isn't "manage your WordPress plugins more carefully." It's that the plugin-dependent architecture itself is the liability. As long as your site's core functionality — forms, bookings, content management, SEO tooling — runs through a stack of independently maintained third-party code sitting on a live, publicly accessible server with a database connection, you are exposed to this ecosystem's failure rate, no matter how careful you personally are. We go into the plugin-by-plugin comparison in more detail in our piece on what Supabase replaces — most of what a typical business plugin stack handles has a cleaner, more secure equivalent once you're off WordPress entirely.
Want us to look at your setup?
Free 24-hour audit. No pitch, no pressure.
How the GitHub + Astro + Supabase Architecture Removes This Attack Surface
This is the architectural shift we make for clients, and it's worth explaining plainly why it closes the door on plugin-based attacks rather than just reducing the odds.
When we rebuild a site on Astro, the output is a set of static files — HTML, CSS, and JavaScript that are generated once at build time and then served directly, with no live application code executing on the server for every visitor request. That distinction matters more than it sounds like it should. A WordPress site is a live application: every page load runs PHP code, queries a database, and executes whatever plugin logic is attached to that request. That live execution path — PHP interpreter, database connection, plugin hooks — is exactly what all three attack categories above depend on. Authentication bypass needs a login system to bypass. SQL injection needs a database query to hijack. Stored XSS needs a dynamic page that renders attacker-controlled input back to visitors.
A static site removes that path entirely. There's no PHP interpreter exposed to the public internet for an attacker to exploit, and no live database connection sitting behind the page a visitor is looking at. The pages being served are just files — there's no application logic running on that request for an authentication bypass or SQL injection to target in the first place. This isn't a security feature bolted onto the site. It's a structural property of how the site is built.
Where a site does need dynamic functionality — a contact form, a booking flow, gated content — that logic lives in Supabase, a managed backend with its own access controls, isolated from the public-facing site files and governed by row-level security policies we define explicitly for each use case. Instead of a form plugin with database write access sitting inside the same WordPress install as twenty other plugins, form submissions go through a scoped, audited database connection built for exactly one purpose. There's no shared plugin ecosystem for a vulnerability in one feature to spread from into every other part of the site.
The result isn't "a more secure WordPress site." It's a site with no plugin ecosystem to be vulnerable in the first place — no weekly stream of 250+ new plugin disclosures to track, no 5-hour exploitation windows to lose, no third-party developer's patching backlog standing between your site and the next automated scanning bot. We walk through the full mechanics of this migration, step by step, in our 30-day WordPress-to-Supabase migration playbook, and if performance is part of what's motivating the move too, our Astro vs. WordPress Core Web Vitals comparison covers the speed side of the same architectural shift.
What to Look For If You're Not Ready to Migrate Yet
Not every business is ready to rebuild their site tomorrow, and that's a legitimate position. If you're staying on WordPress for now, a few concrete steps meaningfully reduce (though don't eliminate) your exposure:
- Audit every active plugin. If you don't know why a plugin is installed or the last time it was updated, that's a candidate for removal — every inactive or abandoned plugin is still an attack surface even if you're not using its features.
- Check plugin update history, not just star ratings. A plugin with 4.8 stars and 500,000 installs that hasn't shipped an update in two years is a bigger risk than a newer plugin actively maintained by a responsive developer.
- Limit admin accounts and enforce strong, unique credentials, since authentication-related flaws are the largest single vulnerability category.
- Keep offsite, automated backups that aren't themselves stored through a WordPress backup plugin with its own attack surface — a compromised site with a clean, recent backup is a bad day; a compromised site without one can be a business-ending one.
- Monitor for unexpected admin accounts, file changes, or search-console malware warnings rather than assuming silence means safety — most compromises go unnoticed by the owner for weeks.
These steps reduce risk. They don't remove the structural exposure that comes from running live, third-party plugin code in the first place — but they're a reasonable interim posture while you evaluate a longer-term move.
Why Automated Attacks Target WordPress at This Scale
It's worth understanding the economics driving the volume covered above, because it explains why this problem isn't going away on its own. WordPress powers a very large share of all websites on the internet, which means a single working exploit against a popular plugin doesn't just compromise one site — it potentially compromises every site running that vulnerable plugin version, all at once, discoverable through the same automated scanning pass. From an attacker's perspective, that's an extraordinarily favorable return on effort: one piece of exploit code, developed once, can be pointed at millions of potential targets with a simple search for sites running the affected software.
This is precisely why automated scanning bots specifically target WordPress plugin vulnerabilities rather than custom-built, one-off websites. A custom application built for a single business has no meaningful reuse value for an attacker — compromising it teaches them nothing applicable to any other target. A popular WordPress plugin installed on hundreds of thousands of sites is a mass-production opportunity. This dynamic is exactly why removing the shared, popular plugin ecosystem from your site's architecture entirely — rather than just using it more carefully — removes you from this specific category of opportunistic, automated attack.
What a Realistic Attack Timeline Actually Looks Like
Security statistics can feel abstract until you walk through how they actually play out on a real site. Here's a composite, realistic sequence based on the patterns described in the research above:
- Hour 0: A security researcher discloses a new authentication bypass vulnerability in a popular WordPress form plugin, affecting all versions before a specific patch release.
- Hour 1-2: The disclosure is indexed into public vulnerability databases. Automated scanning tools that continuously monitor these databases begin building a target list — every publicly discoverable site running the vulnerable plugin version, found through automated fingerprinting of plugin signatures in page source code.
- Hour 5 (the median): The first real-world exploitation attempt occurs somewhere on the internet, according to the Webmastered research cited above. From this point forward, exploitation attempts against vulnerable sites accelerate as more automated scanning tools incorporate the new exploit.
- Days 1-30: The plugin developer may or may not release a patch during this window — in 23% of cases, according to the same data, no patch exists at all within 30 days.
- Whenever the business owner next checks their WordPress dashboard: If they're diligent, they see an update notification and apply it — but for a meaningful share of sites, this happens after the exploitation window described above has already passed, and the check-in cadence itself is often weeks, not hours.
The uncomfortable truth in this timeline is that the business owner is structurally the last one to know, reacting to a threat that automated systems detected and exploited within hours, using a defense (manual plugin updates) that operates on a timescale of days or weeks. That mismatch — attacker speed measured in hours, defender speed measured in days — is the core dynamic that makes plugin-based WordPress security so difficult to manage through diligence alone.
Compliance and Liability Considerations for Regulated Service Businesses
For certain categories of service businesses, a plugin-based compromise carries stakes beyond reputation and downtime. Dental practices, medical spas, and other healthcare-adjacent businesses that collect any form of patient information through a website form need to think carefully about what data a compromised plugin could expose, and whether that exposure creates compliance obligations under health privacy regulations. Similarly, any service business running online payments or storing card information through a WordPress e-commerce or booking plugin takes on payment card industry security obligations that a vulnerable, unpatched plugin can directly jeopardize.
We're not going to attempt to summarize the specifics of HIPAA or PCI DSS compliance here — that's a conversation for a business's own legal and compliance advisors, not a blog post. But it's worth flagging plainly: if your WordPress site touches patient information or payment data through a plugin, the security posture of that specific plugin isn't just a technical risk, it's potentially a regulatory and liability one, and that raises the stakes on everything covered in this post considerably.
Questions Worth Asking Before You Trust a New Plugin
If you're evaluating whether to install a new WordPress plugin, or auditing what's already running on an existing site, a few concrete questions cut through a lot of the ambiguity:
- When was it last updated? A plugin that hasn't shipped an update in over a year, especially one handling forms, payments, or user data, is a meaningfully higher risk regardless of its install count or star rating.
- Does it have direct database access, or file system write access? Plugins that only affect visual display carry less risk than plugins that read or write to your database, upload files, or modify other plugins' behavior.
- Is the developer a known, established team, or a single unverified author? This isn't a guarantee either way, but a plugin backed by a company with a security disclosure process and dedicated support is generally a safer bet than one maintained by a single hobbyist developer with no formal process.
- Do you actually need it, or did it seem useful once and never get removed? Every plugin sitting inactive or barely used is still exposed attack surface. If you can't articulate why it's there, that's a strong signal it's a candidate for removal.
None of this eliminates the structural risk described throughout this post — it just reduces it at the margins for businesses not yet ready to migrate away from the platform entirely.
The Bottom Line on WordPress Plugin Security
The numbers here aren't ambiguous. WordPress core is secure — six low-priority vulnerabilities in an entire year is a strong track record for software that powers a significant share of the web. The plugin ecosystem built on top of it is a different story: 91% of 2025's 11,334 new vulnerabilities, a 42% year-over-year increase, more than 250 new disclosures every week in 2026, a median 5-hour window before exploitation begins, and better-than-even odds that a reported vulnerability goes public before it's patched. For a service business owner who isn't in the business of tracking CVE disclosures, that's not a risk you can realistically manage down to zero through better habits. It's a structural feature of the platform you're standing on.
That's the calculation that drove us to change our default recommendation for new client builds, and it's the same calculation we walk every prospective client through before we ever talk about design or content. The security case, on its own, is often reason enough to make the switch.
Not sure whether your current WordPress site's plugin stack is putting you at risk? Our free audit looks at exactly what's running on your site today — every plugin, its update status, and where your real exposure sits — so you can make the call on migrating with real numbers in front of you, not guesswork.
How Valley Can Help
We Help Businesses Like Yours Get More Leads — and Close More of Them
The Valley Marketing Group is a Phoenix-based marketing agency specializing in AI-powered lead generation, paid advertising, and web development for local service businesses.
- Google Ads & paid search — campaigns built to generate qualified leads, not just clicks
- AI phone receptionist — never miss a call or lead while you're on the job
- Website design & development — WordPress, Webflow, Shopify, WooCommerce
- SEO content & local search — rank for the searches your customers are already making