Why Your WordPress Site Can Never Be Truly Secure (And It Is Not Your Fault)

This article may make many web agencies uncomfortable. We are writing it anyway, because we believe anyone who entrusts their website to a professional deserves an honest assessment — not one designed to protect the provider’s business model.

WordPress is a remarkable tool. It democratised website creation, lowered barriers to entry, and made it possible for millions of people to have an online presence without knowing how to code. That is not the issue.

The issue is that WordPress carries structural limitations in terms of security that no amount of plugins, updates, or configuration can fully eliminate. And in 2026, with increasingly sophisticated and automated attacks, those limitations carry more weight than ever.

1. The Problem Is Not the Plugins — It Is the Architecture

The standard response when discussing WordPress security is always the same: keep everything updated, use reliable plugins, install a web application firewall. That advice is correct — but it addresses the symptoms, not the cause.

The cause is deeper, and it is structural.

WordPress is an open-source platform built on a principle of maximum extensibility: anyone can write a plugin, anyone can create a theme, anyone can modify any part of the system by adding third-party code. This openness is its greatest strength — and it is precisely its primary vulnerability.

A typical WordPress installation does not run only WordPress code. It runs WordPress plus the code of 10, 20, or 30 plugins written by different developers, in different years, to different security standards. It is like living in a house with 20 separate entrances, each built by a different craftsperson, with different locks, none of which you have personally verified.

Your front door can be impenetrable. If one of the other 19 entrances has a flimsy lock, the house is not secure.

2. The Numbers No One Tells You

These figures come from the CVE (Common Vulnerabilities and Exposures) database and annual reports from Patchstack and WPScan, which track WordPress vulnerabilities:

Over 97% of vulnerabilities detected on WordPress installations in 2025 involved third-party plugins and themes — not the WordPress core itself
The official WordPress.org repository hosts more than 60,000 plugins: it is impossible for any review team to guarantee the code quality of all of them
Free plugins are often developed by individual developers who can stop maintaining them at any moment, without notice
A critical vulnerability in a plugin with one million active installations is actively exploited within hours of publication — not days

The point is not that WordPress is riddled with known vulnerabilities. The point is that the plugin ecosystem creates an attack surface that grows every time you add a new feature — one that cannot be fully controlled no matter how diligent you are.

3. What Plugin Zero-Days Are and Why They Cannot Be Stopped

A zero-day is a vulnerability that exists in the code but has not yet been discovered — or has been discovered by someone with malicious intent before the developers were aware of it.

The name comes from the fact that developers have had “zero days” to prepare: the vulnerability is exploited before any patch exists.

In an ecosystem like WordPress, with tens of thousands of plugins written by developers worldwide with wildly varying skill levels, the number of potential zero-days is by definition impossible to count. No tool can detect them all in advance, because by definition they are not yet known.

When one of these vulnerabilities is discovered and made public, the cycle is always the same:

The vulnerability is published in the CVE database
The plugin developer releases a patch (if they are still active, if they have time, and if they can do it quickly)
Users must update the plugin before automated bots — which continuously monitor CVE feeds — begin exploiting it

The window of time between step 1 and step 3 is the risk zone. And during that window, your site is exposed regardless of how vigilant you are.

4. The Software Supply Chain: The Invisible Risk

There is an even subtler problem that rarely gets discussed outside cybersecurity circles: software supply chain attacks.

Here is how they work: an attacker does not target the website directly. They target the plugin — or the person who develops it. They acquire a popular plugin whose developer has stopped maintaining it, insert malicious code into what appears to be a legitimate update, and within hours that code is running on every site that has automatic updates enabled.

This type of attack is particularly insidious because:

It arrives through the official update channel, which users trust by habit
It can remain dormant for weeks before activating
It is very difficult to detect without a forensic analysis of the code

This is not a theoretical scenario: this type of compromise has been documented in the WordPress.org repository on more than one occasion in recent years. Not frequently — but enough to represent a real risk vector.

5. Updating Is Not Enough: The Exposure Window

“Keep everything updated” is the most common piece of WordPress security advice. It is correct. It is necessary. It is not sufficient.

Why is it not sufficient? Because between the moment a vulnerability is discovered and the moment a patch is released, there is always a time gap — and between the moment a patch becomes available and the moment it is installed, there is another one.

Statistics show that the majority of WordPress sites are compromised within the first 24 to 48 hours of a critical vulnerability being published, while most updates are applied on average 4 to 7 days after availability.

Automatic updates reduce but do not eliminate this window. And for abandoned plugins — where the developer stops responding to security reports — that window never closes.

6. What It Truly Means to Have a Secure Website

Real information security is not built by patching vulnerabilities one by one. It is built by reducing the attack surface from the outset — by choosing architectures that, by their nature, have fewer entry points, fewer third-party dependencies, and less uncontrolled code running on your infrastructure.

In our approach to website development, this translates into specific choices:

No dependency on third-party plugins for critical functions. Contact forms, authentication systems, restricted areas, integrations with external services: everything is developed internally, in code we know line by line and for which we are directly responsible. There is no plugin written by someone else handling your users’ data.

Proprietary encryption of data in transit and at rest. The contact forms we build do not transmit data in plain text: every field is encrypted before leaving the user’s browser. This is not a feature available on WordPress with a plugin — it is an architectural decision that must be implemented at the code level.

Active monitoring and frequent updates. We do not wait for something to break. The sites we manage are monitored continuously: anomalies in traffic, unauthorised access attempts, unexpected changes to the codebase. Security updates are applied within hours, not days.

Full control of the technology stack. We know exactly what is running on every server, who has access to what, and why. There is no plugin ecosystem of unknown origin involved.

The question worth asking is not “how do I make my WordPress site secure?” The more useful question is “do I actually need WordPress, or do I need a website that works well and stays secure?” More often than not, that question leads to a different answer.

FAQ

Is WordPress really that dangerous? Millions of sites use it without problems.

WordPress is not inherently dangerous — it is the most widely used CMS in the world, and millions of sites run without incidents. The point is that “running without visible incidents” does not equal “being secure.” Many compromises remain silent for weeks or months: the site is used to send spam, host phishing pages on subdomains, or mine cryptocurrency in the background. The site owner often does not know until Google places it on a blacklist.

If I use only well-known, updated plugins, am I safe?

You are significantly safer than using abandoned or dubious plugins — but you are not immune. The most widely used plugins are also the ones on which security researchers — and attackers — focus the most attention. Critical vulnerabilities have been found in plugins with millions of active installations, including some of the most trusted names in the repository.

What is the concrete alternative to WordPress?

It depends on the objective. For informational sites, portfolios, and business websites, custom development with modern technologies offers performance and security levels that no CMS can match. For those who need to update content frequently without technical skills, headless CMS platforms like Sanity or Contentful separate the content management backend from the frontend — eliminating most of the attack vectors typical of WordPress. The right choice depends on the specific use case.

Does a custom-developed site cost significantly more?

In the short term, often yes — custom development requires more initial time compared to installing a WordPress theme. In the medium to long term, the calculation changes: you eliminate the costs of premium plugin licences, reduce the risks of downtime and compromises, and gain performance improvements that translate into fewer lost conversions. A compromised site has direct costs (restoration, data loss) and indirect ones (reputation, SEO) that are rarely factored into the initial evaluation.

Why do so many agencies still use WordPress then?

Because it significantly reduces initial development time and cost, and because most clients never explicitly ask for advanced security guarantees. It is an understandable commercial choice. It is not necessarily the right choice for those whose website is the heart of their business or who handle sensitive data.

How do I know if my WordPress site has already been compromised?

Obvious signs — redirects to other sites, unfamiliar content, browser warnings — are often the late-stage indicators. Early signs are more subtle: an anomalous drop in organic traffic (Google penalises sites with malicious content), spam emails being sent from your domain that start landing on blacklists, and admin accounts created without anyone having created them. A tool like Sucuri SiteCheck allows a quick external check. For a deeper analysis, examining the server files and access logs is necessary.

Considering a new website or trying to understand how secure your current setup is? We analyse the situation with no obligation: we evaluate the architecture, the real risks, and the concrete options. Contact us