WordPress has a reputation for being insecure, and after nearly two decades of building and running WordPress sites professionally, I can tell you the reputation is aimed at the wrong target.
WordPress core is not inherently insecure. It’s one of the most scrutinized codebases on the internet, maintained by a dedicated security team, with a formal disclosure process, bug bounties, and automatic background patching for security releases. Serious core vulnerabilities are rare, and when they appear they’re typically patched and auto-deployed to millions of sites within hours. If the software itself were the problem, the web would have burned down years ago: WordPress powers roughly 43% of all websites and holds over 60% of the CMS market.
People Make WordPress Insecure
What actually gets WordPress sites hacked is almost never WordPress. It’s two things layered on top of it:
- Poor hosting environments. Shared servers with outdated PHP, no isolation between accounts, writable filesystems where they shouldn’t be, no WAF, no malware scanning, FTP still enabled, and backups that turn out not to exist. A hardened host with PHP isolation, sane file permissions and an edge firewall removes entire categories of attack before WordPress even gets involved.
- Poorly written plugin and theme code. This is where the overwhelming majority of real-world WordPress vulnerabilities live. Every statistics roundup from the security vendors says the same thing year after year: plugins account for well over 90% of disclosed WordPress vulnerabilities, with core itself a rounding error. An unvetted plugin runs with full application privileges; installing one is a trust decision, not a feature decision.
In other words, people have the ability to make WordPress insecure, and many exercise it enthusiastically: fifty plugins of unknown quality, a theme bought from a marketplace and never updated, admin passwords reused from a breached service, hosting chosen on price alone. None of that is a WordPress problem. The same choices would compromise any platform.
Why You Hear About WordPress Hacks Constantly
WordPress is the most used CMS software in the world, and that fact alone explains most of its reputation. When something powers 43% of the web, three things follow naturally:
- It’s the biggest target. Attackers automate, and automation goes where the installs are. A WordPress exploit has tens of millions of potential targets; an exploit for a niche CMS has thousands. The volume of attacks against WordPress is a function of its popularity, not its quality.
- Every incident gets reported as a “WordPress hack.” When a site running an abandoned slider plugin on a $3 host gets defaced, the headline says WordPress. The equivalent compromise of a custom-built site gets no headline at all, because there’s no brand name to put in it.
- The denominator is invisible. You hear about the compromised sites and never about the hundreds of millions quietly running fine. Judging WordPress security by hack headlines is like judging car safety by only ever reading crash reports for the best-selling model.
My Own Track Record
Throughout the years, across every site I’ve built and managed, from solo-founder businesses to enterprise publishers handling millions of visitors and real revenue, not a single one has been hacked or compromised. That’s not luck, and it’s not a security suite. It comes down to a few deliberate habits:
- Minimal systems. The less code you run, the less there is to exploit. I build custom themes with exactly what the site needs, keep the plugin list short and boring, and remove anything that isn’t earning its place. Most of my production sites run a fraction of the plugins a typical install carries.
- Smart hosting. Managed WordPress hosts with proper isolation, current PHP, and platform-level security instead of bargain shared hosting where you inherit your server neighbors’ problems.
- Smarter monitoring and DNS-level protection with Cloudflare. A WAF, bot mitigation and rate limiting at the edge means credential stuffing, exploit scanners and brute-force floods are blocked before they ever reach WordPress. Pair that with real monitoring and you see attack patterns forming instead of discovering them afterward.
- Updates, always, without exception. Core and every plugin stay current at all times, with updates tested through staging and deployed promptly. Nearly every mass compromise in WordPress history exploited a vulnerability that already had a patch available.
- No plugins you’re afraid to update. This is the quiet rule that does the most work. If updating a plugin scares you, that plugin is a liability by definition: it means the code is fragile, abandoned, or so entangled in your site that it controls you instead of the reverse. Replace it. A plugin you can’t update fearlessly is a vulnerability on a delay timer.
Notice what’s absent from that list: security plugins. I don’t run them. Most of what they sell, firewalls, login throttling, scanning, is done better at the DNS and hosting layers, outside the application where an attacker can’t touch it. A firewall running inside the thing it’s protecting is already in the blast radius, and the heavyweight security suites add their own attack surface, their own performance cost, and a false sense of having “handled” security.
You Don’t Need a Closed System to Be Secure
The usual conclusion people reach after a scare is that they should move to a closed, proprietary platform where someone else handles everything. You don’t need a closed system to be secure, and closed systems carry their own risks that rarely make it into the sales pitch:
- Obscurity isn’t security. Closed source means fewer researchers auditing the code, not fewer flaws in it. Vulnerabilities in proprietary platforms exist; you just can’t see them, verify the fix, or audit the code yourself. With WordPress, thousands of researchers probe everything in public, which is uncomfortable and also exactly why issues surface and get fixed.
- You patch on their schedule. In a closed platform you can’t fix anything yourself, hire someone who can, or even confirm a problem exists. You wait, exposed, for a vendor whose disclosure incentives favor silence.
- One vendor, one breach, everyone. Centralized closed platforms concentrate risk: a single compromise of the vendor touches every customer at once, and their incident becomes your incident with zero warning and zero control.
- Lock-in is its own exposure. If the vendor raises prices, sunsets features, suffers an outage or shuts down, your only option is a migration you no longer fully control. Being unable to leave is a business-level security problem.
Security is not a property of open versus closed. It’s a property of how a system is built, hosted, monitored and maintained. WordPress, run with minimal code, serious hosting, edge protection and disciplined updates, is as secure as anything on the web, and I have a couple of decades of unhacked production sites to show for it. The platform was never the problem; the practices around it are, and those are entirely yours to control.