Why Client WordPress Sites Keep Getting Hacked (And It Is Not Your Code)

A client calls on a Friday afternoon. Their site is redirecting visitors to a pharmacy store. Or Google has slapped a warning on it. Or the host suspended the account overnight without much explanation.

Nobody on your team has touched that site in four months. The theme is yours. The custom code is yours. Both are fine.

The way in was a plugin. It usually is.

If you run sites for more than a handful of clients, you have had some version of this weekend. This post is about why it keeps happening, why it is a property of the architecture rather than a failure of diligence, and what the realistic options are — including staying exactly where you are.

Where WordPress Vulnerabilities Actually Live

The important thing to understand is that WordPress core is not the problem. Core has a dedicated security team, ships automatic background updates for minor releases, and has a disclosure process that works. Serious core vulnerabilities are rare and patched fast.

The vulnerabilities are in the ecosystem around it. Tens of thousands of plugins and themes, a large share maintained by one person in their spare time, and a meaningful number abandoned years ago while still running on hundreds of thousands of live sites. Year after year, the overwhelming majority of publicly disclosed WordPress vulnerabilities are found in plugins and themes rather than in core.

That distinction matters more than it first appears, because of what installing a plugin actually does.

You are not adding a feature. You are adding third-party PHP that executes on your server, inside your application, with access to your database and your filesystem, on every single request. A contact form plugin and a payment plugin have exactly the same privileges. So does the slider plugin someone installed in 2021 to fix one page and never removed.

Three patterns account for most of what we see:

• Abandonment. A plugin stops being maintained. It does not announce this. It keeps working perfectly, which is precisely the problem — nothing about the site looks wrong until a vulnerability is disclosed and there is no patch coming.
• Popularity as a target. A plugin on 200,000 sites is worth a researcher's time and an attacker's. Disclosure is public, and mass scanning for the vulnerable version starts within hours.
• Supply chain. A maintainer sells a popular plugin. The new owner pushes an update that adds tracking, injected links, or a backdoor. The site owner sees a routine update notification.

None of these are things an agency can prevent by being careful. You can only react faster.

Why This Is Architecture, Not Carelessness

It is tempting to read the above as "WordPress users are sloppy." That is not it. Three structural decisions produce the risk, and all three are deliberate.

The CMS and the public website are the same application. The thing your visitors load and the thing your client logs into are one PHP application, on one server, sharing one database. There is no boundary to cross because there is no boundary.

Plugins run server-side with full privileges. WordPress's extensibility is the reason it won. Hooks and filters let plugin code run at almost any point in the request lifecycle. That is enormously powerful, and it means a vulnerability in any installed plugin is a vulnerability in the whole site.

The admin login sits on the public domain. /wp-admin and /wp-login.php are on the same hostname as the marketing site, reachable by anyone. Automated credential-stuffing against them starts within hours of a domain going live — not because you were targeted, but because everything is scanned.

Put together: the attack surface is not something bolted onto WordPress. It is what makes WordPress WordPress. The plugin ecosystem that lets a small agency ship a booking system in an afternoon is the same mechanism that puts unreviewed third-party code in the request path of a client's site.

Where WordPress Still Wins

Any comparison that skips this part is marketing, so let us be straight about it. There are good reasons WordPress runs a large share of the web, and for a lot of projects it remains the right call.

The ecosystem is unmatched. Whatever the client wants — events, memberships, a specific payment provider, an obscure CRM integration — something already exists. Building the equivalent from scratch is real money.

Cost and speed on simple sites. For a five-page brochure site with a blog and a contact form, WordPress with a decent theme is hard to beat on time-to-launch or on budget. Insisting on a custom stack there is engineering for its own sake.

Talent availability. You can hire WordPress skills in any city at any price point. That is not true of every stack, and it matters for maintenance over a five-year horizon.

Clients already know it. Many of them have used the admin before. Familiarity has a real value that is easy to dismiss until you are the one running the training session.

If the site is low-risk, the budget is small, and someone is genuinely committed to keeping plugins patched — WordPress is a reasonable, defensible choice. The problems start when the site matters, the retainer does not cover maintenance, and nobody is actually watching.

What Decoupling Changes

The alternative that has become standard for agencies running many client sites is to separate the two jobs WordPress does at once: managing content, and serving the website.

In a decoupled setup the CMS runs on its own infrastructure. The public site is a separate application that reads content over an API with a read-only token and renders pages. That single split changes the security picture structurally, not incrementally:

• There is no admin login on the site being served. No /wp-admin to brute-force, because the admin is not there. The credential-stuffing traffic that hits every WordPress site has nothing to hit.
• No third-party code executes on the public site. There is no plugin runtime because there is no plugin system. Functionality is code in your own repository, reviewed and deployed like the rest of your work.
• The database is not reachable from the public site. It reads content through an API with a token scoped to published content. A compromise of the front end does not hand over the content store.
• Patching happens in one place. One platform, upgraded once, rather than the same update applied separately to every site you maintain.

The categories of attack that account for most WordPress compromises do not get harder in this model. They stop having anywhere to land.

What You Give Up

Honestly: convenience, and some flexibility.

There is no two-click install for a new capability. Adding a new type of content block means a developer writes a component. Your client cannot browse a marketplace and solve their own problem at 11pm — which is a loss when the plugin was going to work, and a relief every other time.

You also take on a stack that fewer people know. That is a real consideration when you think about who maintains the site in three years.

This is a genuine trade. You are exchanging the ability to install anything for the guarantee that nothing unreviewed runs on your client's site. For a brochure site that trade may not be worth it. For a site that takes payments, holds personal data, or carries a brand that cannot survive a defacement, it usually is.

If You Are Staying On WordPress

Most agencies will keep a WordPress book of business, and that is fine. If you do, the work is to shrink the surface rather than pretend it is not there:

• Inventory and prune ruthlessly. Every plugin you remove is attack surface deleted permanently. Audit what is installed on every site and delete anything not clearly earning its place — deactivated plugins still sit on disk and can still be reachable.
• Check maintenance status, not just version numbers. A plugin last updated three years ago is a liability even if it currently reports no vulnerabilities.
• Get the login off the open internet. Restrict /wp-admin by IP where you can, put it behind SSO or a WAF rule, and enforce multi-factor authentication for every account with publishing rights.
• Remove admin accounts nobody uses. Old freelancer accounts and the client's former marketing manager are standing risk with no upside.
• Automate updates and actually monitor them. Unattended updates plus alerting beats a quarterly reminder that gets skipped when a project runs late.
• Have backups you have restored. An untested backup is a hypothesis. Restore one to a staging environment and confirm it works before you need it at 2am.
• Test it like an attacker would. Periodic penetration testing finds the exposed staging subdomain, the forgotten admin panel and the plugin nobody remembers installing — the things an inventory on paper does not surface.

None of this makes the architectural exposure disappear. It does make you a much harder target than the site next door, which is most of what practical security buys you.

The Question Worth Asking

The useful question is not "is WordPress secure?" — a well-maintained WordPress site is more secure than a neglected site on any stack.

The question is: who is responsible for keeping it secure, and is that reflected in what you charge?

If a client's retainer does not fund someone watching plugin advisories, testing updates and responding when something is disclosed, then nobody is doing it. The site is not being maintained; it is being left alone until it breaks. And when it does, the client's first call is to the agency that built it, whatever the contract says.

That is the calculation that pushes agencies towards a managed, decoupled platform: not that WordPress is bad, but that the maintenance burden of running a dozen of them properly is real, recurring, and rarely priced in.

We built Privum CMS for exactly that position — a managed, multi-tenant CMS where your clients edit their own content, your design stays under your version control, and the platform is penetration tested on a fortnightly cycle by the same engineers who run external security assessments for our consulting clients. There are no plugins to patch, and no admin panel on the site your visitors load.

If you want a second opinion on what your current client estate actually exposes, talk to our security team — an external assessment tells you what is really reachable, which is usually not the same as what the inventory says.

Related reading: how email spoofing works and what it costs — the same lesson about attack surface, applied to the domain rather than the site.