We Scanned 32,000+ WordPress Sites: What We Discovered About Ecosystem Security

Key Takeaway: In August 2026, Vioro conducted an outside-in empirical audit of 32,036 live WordPress domains. The study revealed that 61.2% of sites (19,616 domains) run outdated or vulnerable plugins, 20.5% (6,561 domains) remain stranded on unsupported legacy core versions (v6/v5/v4), and 29.3% operate within a routine 6-day minor patch window. Unpatched vulnerabilities in popular plugins and standardized agency blueprints represent the primary real-world attack vectors.

When you ask web developers or agency teams if their WordPress sites are secure, the common answer is that auto-updates are enabled and a security plugin is installed. Yet internal dashboards often report what they expect to see rather than what an external observer can verify.

To test what WordPress security actually looks like across the open web, we conducted an empirical, outside-in scan across 32,036 live domains.

Here is what the data showed, how we gathered it politely, and what the numbers tell us about modern web security.

Responsible Disclosure & Data Protection

Before examining the numbers, a critical note on ethics and data privacy:

Data Protection Commitment: Under no circumstances do we publish raw domain lists, specific version numbers tied to identified websites, or weaponized vulnerability targeting maps. All findings presented in this report are strictly aggregated and anonymized to protect website owners and their users.

Our goal is to shine a light on systemic architectural patterns across the ecosystem, rather than providing targeting information for bad actors.

Methodology: Outside-In Passive Fingerprinting with VioroBot

To gather this dataset without degrading site performance or triggering false alarms, we utilized VioroBot , our custom outside-in crawler.

flowchart TD
    subgraph Recon["1. Outside-In Reconnaissance"]
        A["VioroBot Passive Scanner"]
        B["Target WordPress Site"]
        A -->|"Public HTTP GET"| B
        B -->|"Public HTML & Assets"| A
    end

    subgraph Analysis["2. Passive Forensic Analysis"]
        C["Inspect Meta Generator Tags"]
        D["Analyze Asset Version Parameters (?ver=X.X)"]
        E["Examine Plugin Comment Signatures & Hashes"]
        C --> D --> E
    end

    subgraph Intel["3. Defense Intelligence Mapping"]
        F["Match Known CVE Database & Release Indexes"]
        G["Aggregated Ecosystem Security Posture"]
        F --> G
    end

    A --> C
    E --> F

The Non-Intrusive Principles

1. Zero Plugins Required: We did not install or require any software on target servers.
2. No Active Exploitation or Fuzzing: We performed no payload injection, no brute-force authentication attempts, and no invasive directory traversal.
3. Respectful Crawl Politeness: VioroBot strictly respects robots.txt, operates with rate limiting and low concurrency, and clearly identifies itself via standard User-Agent headers (viorobot/v<version.number> (+https://vioro.io/bot)).
4. Targeted Passive Forensics: Detection relies on analyzing publicly accessible signals: meta generator tags, version query parameters on static assets (?ver=X.X), HTML comment signatures from popular plugins, and static asset file checksums.
5. Precision vs Botnet Reconnaissance: Automated botnets blindly spray thousands of intrusive requests, fuzzing input parameters and hammering login endpoints. This causes heavy server load and triggers WAF bans. In contrast, VioroBot extracts security posture from a single polite request to public pages. This approach is more precise, avoids false alarms, and uses minimal server resources.

The Big Picture: Key Findings at a Glance

Across the 32,036 analyzed domains, the data reveals significant exposure across core versions, plugin stacks, and shared management networks:

Classification Note:

• Legacy Vulnerable Core: Domains running WordPress major branches (such as 6.x, 5.x, 4.x, and earlier) that contain publicly cataloged CVEs with published exploit chains.
• Outdated or Vulnerable Plugins: Domains running installed plugin versions with known published CVEs or falling behind the latest stable release observed in the ecosystem.

Let us examine each of these findings in detail.

Finding 1: The Core Version Divide (6-Day Patch Lag vs. Legacy Major Stranding)

When analyzing WordPress core versions, context is everything.

WordPress 7.x and its subsequent maintenance updates have been available for months. The latest stable minor release in this analysis cycle was published on August 19, 2026. Our scan dataset was finalized on August 25, 2026, just 6 days later.

All Scanned Domains (32,036)
├── 50.2% (16,068) Up-to-Date on Latest Release
└── 49.8% (15,968) Below Latest Release
    ├── 29.3% (9,407) Routine 6-Day Patch Lag (Recent Branch)
    └── 20.5% (6,561) Critical Legacy Stranding (v6.x, v5.x, v4.x)

1. The 6-Day Routine Patch Lag (29.3%)

Approximately 29.3% of sites (9,407 domains) were running the immediate prior minor release. For organizations running scheduled staging review cycles or CI/CD deployment windows, a 6-day delay is standard operational procedure.

2. The Critical Legacy Stranding (20.5%)

What is alarming, however, is that 6,561 domains (20.5% of the total dataset) are not just a few days behind on a minor point release. They are completely stranded on legacy major versions:

• Running branches such as WordPress 6.x, 5.x, or 4.x.
• Exposed to dozens of publicly documented Common Vulnerabilities and Exposures (CVEs) with readily available exploit scripts.

During our scan, we even encountered extreme historical relics, including websites still running WordPress 2.0.11 (a version first released in 2008).

Why Do Sites Get Stranded?

In our experience auditing production systems, core auto-updates frequently fail or get disabled due to three common factors:

1. Custom Theme and Plugin Incompatibility: A bespoke theme or legacy custom plugin breaks on newer PHP or WordPress major releases. Rather than refactoring the code, developers pin legacy versions indefinitely.
2. DISALLOW_FILE_MODS and Disabled WP-Cron: Hardened server configurations that disable core auto-updaters without implementing an automated external deployment pipeline.
3. Orphaned Client Projects: Sites built years ago by an agency or freelancer where the maintenance retainer lapsed, leaving no one responsible for ongoing security updates.

Finding 2: Why Do 61.2% of WordPress Sites Run Outdated Plugins?

While core security gets the headlines, third-party plugins represent over 90% of the entire WordPress attack surface.

WordPress core has a dedicated security team and benefits from automated background updates for minor releases. In contrast, the WordPress repository hosts over 60,000 third-party plugins. Many are maintained by solo developers, rarely receive independent code audits, and frequently contain vulnerabilities like SQL injection, cross-site scripting (XSS), arbitrary file uploads, and authentication bypasses.

In our scan, 19,616 out of 32,036 domains (61.2%) were running at least one plugin version lower than the latest stable release observed in the ecosystem.

Plugin Posture (32,036 Domains):
[████████████░░░░░░░░] 61.2% Outdated/Vulnerable (19,616)
[████████░░░░░░░░░░░░] 38.8% Up-to-Date (12,420)

The Heavy Hitters: Extreme Market Concentration

The data revealed massive market concentration in a small group of widely installed plugins:

Top Detected Plugins:
Yoast SEO:       [████████████] 31.9% (10,220 sites)
Elementor:       [████████░░░░] 21.4% (6,855 sites)
Contact Form 7:  [██████░░░░░░] 15.4% (4,928 sites)

1. Yoast SEO (wordpress-seo): Detected on 10,220 domains (31.9%).
2. Elementor (elementor): Detected on 6,855 domains (21.4%).
3. Contact Form 7 (contact-form-7): Detected on 4,928 domains (15.4%).
4. Other Prevalent Plugins: WooCommerce, LiteSpeed Cache, Really Simple Security, WPForms, and Advanced Custom Fields.

Why This Concentration Attracts Exploit Automation

When a vulnerability is discovered in an obscure plugin with 200 installs, attackers rarely bother building automation. But when a vulnerability is published for high-volume plugins like Elementor, LiteSpeed Cache, or Really Simple Security, the economics change overnight.

Botnet operators weaponize public CVEs within 24 to 48 hours. They scan IPv4 ranges looking for matching asset fingerprints. If you run one of these high-volume plugins and let it sit unpatched for even a few days, your server will almost certainly receive automated exploit traffic.

Finding 3: The Agency Supply Chain Multiplier & Shared Blueprint Risk

One of the clearest patterns in the dataset emerged when analyzing parent hop paths, shared hosting clusters, and agency infrastructure.

What is a Hop and How We Discovered Connections

During web crawling, a “hop” represents a link traversal or infrastructure connection discovered between domains. This includes:

• Agency Footer Credits: Backlinks such as “Website designed by Agency X” or “Managed by Agency Y”.
• Shared DNS and Reverse-IP Clusters: Groups of distinct client domains hosted on the same dedicated server or nameserver pool.
• Shared Static Asset CDNs: Custom CDN endpoints or subdomains used across client portfolios.

When mapping these hops across the dataset, single agency nodes frequently linked to dozens or hundreds of active client websites across our scanned fleet.

flowchart TD
    subgraph Blueprint["Agency Core Blueprint"]
        A["Web Development Agency"]
        BP["Standardized Starter Template & Bundled Plugins"]
        A --> BP
    end

    subgraph Fleet["Deployed Client Fleet"]
        C1["Client 1: E-Commerce Store"]
        C2["Client 2: Corporate Portal"]
        C3["Client 3: Healthcare Service"]
        C4["Client 4: Real Estate Platform"]
        C1 --- C2 --- C3 --- C4
    end

    subgraph Exposure["Cascading Vulnerability Exposure"]
        Vuln["Unpatched CVE in Bundled Plugin"]
        Impact["Simultaneous Portfolio Risk Across All Clients"]
        Vuln --> Impact
    end

    BP --> C1
    BP -.-> Vuln

The Standardized Blueprint Trade-Off

Using a standardized blueprint (starter theme, pre-vetted plugin stack, and deployment configuration) is smart engineering for agencies. It reduces setup time from days to minutes and enforces code consistency across client projects.

However, this shared architecture creates an inherent blast radius:

1. Replicated Vulnerabilities: If an agency’s standard starter kit contains a plugin that is later abandoned or develops an unpatched vulnerability, every single client launched on that template inherits the identical exposure.
2. Cross-Site Contamination: If one client site on a shared server gets compromised, attackers can leverage shared credentials or file permissions to move laterally to neighboring client domains.
3. Reputational Multiplier: A single high-profile breach at one client can jeopardize the agency’s entire business reputation across all clients.

For agencies, standardized blueprints are a huge productivity win, but they require continuous external fleet monitoring to alert the team the moment any component across client sites falls out of compliance.

Why Do “Inside-Out” Monitoring Plugins Fail During Server Outages?

The traditional response to website security is to install an all-in-one security plugin. But as we discussed in our architectural deep dive on WordPress Monitoring Plugins , this approach creates serious paradoxes:

1. Expanding the Attack Surface: Every security plugin adds thousands of lines of PHP code, database tables, and REST API endpoints. If that plugin has a vulnerability, the tool meant to protect you becomes the entry point used against you. Examples include the critical authentication bypass in Really Simple Security ( CVE-2024-10924 ) and unauthenticated privilege escalation in LiteSpeed Cache ( CVE-2024-28000 ).
2. Real-World Vulnerability Findings: In our own security research, we discovered a JWT validation bypass in the SYSSY monitoring plugin where expired authentication tokens were accepted indefinitely due to flawed payload handling ( read our SYSSY security advisory ).
3. Silent Internal Failure: When a server runs out of memory, hits a database deadlock, or experiences PHP fatal errors, internal monitoring plugins crash right alongside the website. They cannot alert you that your site is down because they are down too.
4. Attacker Perspective Disconnect: Internal plugins check file integrity on disk, but they often fail to notice what an external attacker sees: exposed version query parameters, misconfigured HTTP headers, or leaked API routes.

flowchart TD
    subgraph InsideOut["Traditional Inside-Out Monitoring (High Risk)"]
        direction TB
        PHP["WordPress Core & PHP Runtime"]
        SecPlugin["Heavy Security / Monitoring Plugin"]
        AP["Expanded Attack Surface & Auth CVEs"]
        Fail["Plugin Crashes During Server Outages / OOM"]
        PHP --> SecPlugin
        SecPlugin --> AP
        SecPlugin -.-> Fail
    end

    subgraph OutsideIn["Vioro Outside-In Monitoring (Zero Footprint)"]
        direction TB
        Cloud["Vioro External Cloud Scanners"]
        LiveSite["Target Website (Public Perspective)"]
        Truth["Independent Checks: TLS, Uptime, Headers, CVEs"]
        Alert["Instant Alerting Even During Server Down"]
        Cloud -->|"Polite Public Probe"| LiveSite
        Cloud --> Truth
        Truth --> Alert
    end

By scanning from the outside, Vioro provides the exact visibility that external security observers have, with zero server overhead and zero added attack surface.

Actionable Next Steps: Hardening Your Fleet Today

Based on our analysis of 32,036 domains, here are four concrete steps you can take today to protect your sites:

1. Audit and Prune Your Plugin Stack

• Deactivate and delete unused plugins. Deactivated plugins can still contain executable PHP files accessible via direct URL requests.
• Replace niche, unmaintained plugins with modern, actively supported alternatives.

2. Remediate Legacy Core Versions

• Check all client domains for legacy branches (v6.x, v5.x, v4.x).
• If custom code prevents updating to modern WordPress versions, prioritize refactoring immediately. Legacy versions are actively targeted by automated CVE scanning tools.

3. Establish Outside-In Continuous Monitoring

• Do not rely solely on inside-out plugins that can fail silently during outages.
• Monitor your sites from an independent, external perspective that continuously checks uptime, TLS certificate validity, and exposed component versions against live CVE feeds.

4. Run an Instant Baseline Check

You do not have to wait for an incident to know where you stand. You can test your domain right now with Vioro’s free external scanner to check your TLS status, response headers, and external fingerprinting posture in under 10 seconds.

Run Free Instant Baseline Scan

Conclusion

The numbers show that over 61% of sites run outdated plugins and 20% remain on vulnerable legacy cores.

Security is not about hoping attackers will overlook your site. It is about eliminating the easy, automated entry points before they find you.

Patch regularly, audit your plugins, and monitor your infrastructure from the outside.