WordPress, Update Anxiety, and the Ecosystem That Refuses to Patch

The scale of the problem

WordPress runs roughly 43% of the web. That number has been stable for years. It is the largest single CMS deployment on the planet, and it includes everything from personal blogs with three visitors a month to e-commerce operations processing six figures annually, to enterprise publishing platforms belonging to major media companies.

The scale is the first fact that matters because it changes the threat model. For any individual site, the probability of being targeted is low. For the ecosystem as a whole, the aggregate attack surface is enormous — and attackers optimize for the aggregate. A vulnerability in a plugin used by 100,000 sites is worth more to a criminal operation than a vulnerability in one site’s custom code, no matter how severe the latter is.

This is the economy of scale that WordPress creates. It makes the platform attractive to developers because everything is available, and it makes it attractive to attackers because everything is exposed.

Why WordPress is targeted

Three characteristics make WordPress the preferred target for automated exploitation.

A known version. Every WordPress installation exposes its version in the HTML head, in the RSS feed, in the /readme.html file, and in the source of every page. A curl request reveals it in one line:

curl -s https://example.com/ | grep -i generator
# <meta name="generator" content="WordPress 5.8.1" />

Knowing the version means knowing which CVEs apply. There is no reconnaissance phase — the target announces what it is running.

A known plugin inventory. WordPress sites load JavaScript and CSS files from /wp-content/plugins/<plugin-name>/. Every loaded plugin appears in the page source. A scraper can build the complete plugin inventory of a target in seconds:

curl -s https://example.com/ | grep -oE '/wp-content/plugins/[^/]+' | sort -u

For each plugin, the version is often exposed in the query string of the loaded file (?ver=1.2.3). Combined with the plugin name, the attacker knows exactly which version of which plugin is running — and can cross-reference against a public database of known vulnerabilities.

A public vulnerability database. WPScan, CVE, and several commercial feeds maintain comprehensive databases of WordPress, plugin, and theme vulnerabilities. The information is public, searchable, and updated within days of a vulnerability becoming known. An attacker does not need to discover the vulnerability — they need to look it up.

The combined effect: an attacker can enumerate the version, the plugin inventory, and the plugin versions of an arbitrary WordPress site in under a minute, cross-reference against known vulnerabilities, and identify every exploitable entry point. Automating this for a million sites is a weekend project.

The update problem

The defensive answer to all of this is obvious: update. WordPress core releases security patches regularly. Plugins and themes release updates when vulnerabilities are found. Running current versions closes the vulnerabilities.

In practice, a large fraction of WordPress installations are not current. The reasons are consistent across the ecosystem.

The breakage fear. The most common reason: “if I update, my site will break.” This is not paranoia — it is a real phenomenon. Plugin updates sometimes introduce incompatibilities. A theme that worked with an older WordPress version may fail after an update. A custom modification to a plugin file is overwritten by the update and disappears. These things happen, and when they do, the site is down.

The problem is the response. A rational approach would be to test updates in a staging environment before applying them to production. That requires infrastructure, discipline, and time. A common approach is to disable automatic updates and never update anything. That also prevents breakage — until the site is compromised by one of the vulnerabilities the update would have patched.

The complexity trap. A WordPress site that was built quickly — a landing page for a marketing campaign, a store for a small business, a course platform for a “guru” selling content — often accumulates fifty or more plugins. Each plugin is a potential source of breakage. Each plugin needs to be updated independently. The update process becomes a project in itself, and it is easier to defer it indefinitely than to do it.

The handoff problem. A site is built by a freelancer. The freelancer hands it to the client. The client does not know how to update, does not know what a plugin is, and does not have a relationship with a developer who is willing to update a site they did not build. The site sits. The plugins age. The vulnerabilities accumulate.

The “it works, don’t touch it” philosophy. This is the most damaging attitude and the hardest to argue against because it is emotionally intuitive. The site is currently working. Any change risks breaking it. Therefore, do nothing. The fact that the site is running software from 2019 with known critical vulnerabilities is invisible — until it is exploited, and by then the damage is done.

The plugin supply chain

WordPress plugins are the weakest link in the ecosystem for a structural reason: the barrier to entry is essentially zero.

A plugin is a folder with a PHP file and a metadata header. Anyone can write one. Anyone can distribute it through the official directory, through third-party marketplaces, or through direct download. The review process for the official directory is minimal — it catches obvious malware but does not audit for security issues in the plugin’s logic.

The consequences:

Abandoned plugins. A developer writes a plugin, publishes it, gains a few thousand users, and then loses interest. The plugin stays in the directory. Users keep installing it. The plugin is never updated. When a vulnerability is found, there is no one to patch it. The official directory eventually removes abandoned plugins, but the process is slow and the plugin remains in use on existing installations long after removal.

Premium plugin markets. Plugins sold on ThemeForest, CodeCanyon, and similar marketplaces are not subject to the same review as the official directory. The code quality varies enormously. Some are well-maintained and security-conscious; many are not.

Pirated plugins. A category of WordPress user installs nulled (cracked) premium plugins. These are distributed through forums, Telegram channels, and torrent sites. They are a reliable vector for backdoors — the “premium” plugin works, but it also contains code that establishes a hidden admin account, exfiltrates credentials, or provides the distributor with remote access.

Plugin bundling. Themes frequently bundle plugins. Installing a theme can install five or six plugins without the user explicitly choosing them. The user is not told which plugins were installed, does not know to update them, and does not recognize them when they appear in the dashboard.

Themes and the same problem

The theme is the other half of the equation. WordPress themes are not just visual templates — modern themes contain PHP logic, custom post types, shortcodes, and often their own bundled plugins. A vulnerable theme is as exploitable as a vulnerable plugin.

Premium themes are sold on marketplaces that do not audit security. Free themes from the official directory are reviewed, but the review is not comprehensive. Both categories have a lifespan — a theme is actively maintained for a few years after release and then abandoned, leaving users with no upgrade path except to switch themes, which requires rebuilding the site.

The exploitation workflow

The attacker’s workflow for compromising a WordPress site is mechanical.

Step 1 — Enumerate. Determine the WordPress version and the plugin/theme inventory. This is done with automated tools like WPScan, or with a few curl requests and a parser.

wpscan --url https://example.com --enumerate vp,vt,u

The vp flag enumerates vulnerable plugins, vt vulnerable themes, and u users. The output includes CVE identifiers and exploit references for anything found.

Step 2 — Cross-reference. For each plugin and version found, look up known vulnerabilities in a public database. WPScan maintains its own database; CVE feeds and vendor advisories are other sources. Many vulnerabilities have public proof-of-concept exploits available on GitHub, Exploit-DB, or in the WPScan database itself.

Step 3 — Exploit. Use the known vulnerability to gain access. Common categories:

• SQL injection in a plugin’s AJAX handler → dump the wp_users table → crack password hashes offline.
• Arbitrary file upload in a plugin’s form handler → upload a PHP web shell → full control of the server.
• Local file inclusion in a plugin’s shortcode handler → read wp-config.php → extract database credentials.
• Authentication bypass in a plugin’s login flow → direct access to the admin dashboard.
• Cross-site scripting → steal an admin session cookie → assume admin privileges.

Step 4 — Persistence. Once inside, the attacker establishes persistence. Common mechanisms:

• Create a new admin user with a plausible name.
• Modify an existing theme or plugin file to include a backdoor.
• Install a malicious plugin that appears legitimate.
• Add a scheduled task (via the plugin API) that re-establishes access if the initial mechanism is removed.

Step 5 — Monetize. What the attacker does with the access depends on their objective. Some possibilities:

• SEO spam. Inject spam links and pages, selling traffic to advertisers.
• Malware distribution. Modify the site to serve malicious JavaScript to visitors, redirecting them to phishing pages or exploit kits.
• Credential harvesting. Add a fake login form to the wp-admin page, capturing admin credentials from real users.
• Ransomware. Encrypt the site’s files and demand payment — less common on shared hosting but present on VPS deployments.
• Data theft. Exfiltrate customer data from an e-commerce site, sell it on the underground market.
• Crypto mining. Inject a JavaScript miner that runs in visitors’ browsers.

The e-commerce and “guru” problem

There is a specific category of WordPress user that is disproportionately affected: small businesses, e-commerce operations, and content creators whose entire revenue depends on their site.

The pattern:

A “guru” sells an online course. They built the site three years ago with a freelancer. The site uses WooCommerce, a page builder plugin, a membership plugin, a payment gateway plugin, and eight other plugins. Two of the plugins are premium plugins that were bought once and never renewed. The site has 400 students and generates €15,000 a year.

The site is running WordPress 5.9 (released January 2022). Several plugins are two or three major versions behind. Three of the plugins have known vulnerabilities that were patched in versions the site has not installed.

The “guru” does not update because “the site works, and last time I updated, the checkout broke.” The site is discovered by an automated scanner, exploited through a vulnerable plugin, and injected with a redirect that sends mobile visitors to a phishing page.

The breach is discovered when a student complains that the site is asking for credit card details on a page that looks different. By then, the site has been compromised for three weeks, customer data has been exfiltrated, and the “guru” is facing a GDPR complaint and a wave of cancellations.

This pattern is repeated thousands of times a year. The victims are not ignorant of security as a concept — they are simply not technologists, they were sold a site by someone who built it once and moved on, and they have no relationship with a developer who maintains it.

The defensive failure is not in the individual’s decision to skip an update. It is in the ecosystem that produces sites with no maintenance plan, run by users who do not know what maintenance means.

Detection

From an operator’s perspective, three detection opportunities.

WordPress-specific scanners. Tools like WPScan, WPScan CLI, and commercial scanners (Sucuri, Wordfence, Patchstack) detect known vulnerabilities and modifications. A regular scan — weekly at minimum — surfaces new issues before they are exploited.

File integrity monitoring. WordPress core, plugins, and themes have known contents. Any modification is a lead. Wordfence and Sucuri provide this as a service; it can also be built with a script that hashes the directory tree and compares against a known-good baseline.

Log analysis. Web server access logs reveal exploitation attempts — a request to /wp-admin/admin-ajax.php with an unusual action parameter, a POST to a plugin’s upload handler, a request for a file that should not exist. Aggregating these into a SIEM and alerting on anomalies catches exploitation in progress.

Admin user audit. A list of admin users should be small and known. A new admin account created without a corresponding onboarding event is an immediate indicator of compromise.

Defense

The controls that actually work, ordered by effectiveness:

Stay current. The single highest-leverage control. Automatic minor updates (which WordPress enables by default for security patches) close vulnerabilities within days of release. Major updates require testing but should not be deferred indefinitely.

Remove unused plugins and themes. Every installed plugin is attack surface. Every deactivated plugin is attack surface that is doing nothing. Delete what is not in use.

Use reputable plugins with active maintenance. A plugin’s last-update date is visible in the directory. A plugin that has not been updated in two years is not a plugin — it is a liability.

Do not use nulled plugins or themes. Ever. The price of the premium version is the price of not having a backdoor.

Enable a WAF. Cloudflare, Sucuri, Wordfence, or a similar service filters the majority of automated exploitation attempts. It does not fix the vulnerability but it blocks the trivial exploit scripts that account for most attacks.

Monitor integrity. A weekly file hash comparison against a known-good baseline detects unauthorized modifications. This is one of the few controls that catches a compromise that has already occurred.

Back up off-site. Backups do not prevent compromise, but they make recovery possible. A backup that lives on the same server as the site is not a backup — it is a copy. The 3-2-1 rule applies: three copies, two media types, one off-site.

Maintain a relationship with a developer. For a business that depends on its site, this is the real fix. A developer who checks in monthly, applies updates in a staging environment, and monitors for issues is worth the cost. The alternative — a one-time build with no ongoing relationship — is how sites end up running 2019 code in 2026.

The update anxiety problem, honestly

The fear of breaking a site with an update is legitimate. Updates do break things. The response should not be to avoid updates, but to make updates safe:

Staging environment. A copy of the site that mirrors production. Updates are applied to staging first. If staging breaks, production is untouched. If staging works, production is updated during a maintenance window.

Incremental updates. Instead of updating everything at once, update one plugin at a time and test after each one. This narrows down which update caused a problem.

Version pinning. Some plugins have options to pin to a specific version. This is not a fix — the pinned version will eventually be vulnerable — but it buys time if the current version has a known issue.

Rollback capability. A snapshot of the site (files + database) before every update. If the update breaks something, the snapshot restores.

None of these require deep technical skill. They require the discipline to set up a process and follow it. The discipline is what most sites lack, and it is the difference between a site that stays secure and a site that appears on the compromise reports.

The scale of the compromise market

It is worth understanding what happens to compromised sites at scale, because it explains why the ecosystem does not self-correct.

Compromised WordPress sites are a commodity. They are bought and sold on underground forums. A site with decent traffic and a good domain reputation sells for tens to hundreds of dollars depending on metrics. The buyer uses it for one of the monetization patterns described earlier, then resells it or abandons it. The site continues to be compromised, sometimes for years, sometimes by multiple actors simultaneously.

This is why many compromised sites are never detected by their owners. The compromise is designed to be invisible to the owner — the site works normally for anyone with an admin cookie, and only serves malicious content to visitors from certain geographies or user agents. The owner sees no problem, the visitors see a problem that they attribute to their own device, and the site continues to operate as a relay for whatever the buyer is doing with it.

The only way to know is to look. Regular scans, file integrity monitoring, and — for sites that generate revenue — a security service. The tooling exists. The market for it exists. The willingness to pay for it is what varies.

Takeaway

WordPress is not insecure. It is widely deployed, and widely deployed systems have more attackers than obscure ones. The vulnerabilities are mostly in plugins and themes, not the core, and they are mostly in old versions that the site owner chose not to update.

The decision not to update is a rational response to a real risk — the risk of breaking the site. The problem is that the alternative risk — the risk of being compromised — is invisible until it happens. The first risk is immediate and visible. The second is delayed and silent. Human psychology, applied consistently at scale, produces the pattern we see: a large fraction of the web running code that should have been patched years ago.

The fix is not awareness training, and it is not a technology that magically patches everything. The fix is a maintenance process that most site owners do not have and most developers do not sell. Until that gap closes, the ecosystem will continue to produce compromised sites at the current rate, and the search engines that index the web will continue to quietly demote them when they are discovered.