What 250,000+ protected sites and 10 years of operational data actually show
Last updated: April 2026 · Data window: Last 30 days (GDPR-compliant retention)
Every WordPress security vendor publishes numbers. Not every vendor explains how those numbers are measured. This page does.
WP Ghost blocks more than 100 million threat attempts every month across the sites running it, including more than 10 million brute force attempts. Those numbers come from aggregated cloud reporting from sites that have Security Threats Log enabled and opted into network-level reporting.
They are also, and this matters, the floor, not the ceiling. We’ll explain why in the Methodology section below.
Alongside network-wide telemetry, this page shares operational observations from the WordPress sites our company has managed continuously since 2016. These two data sources answer different questions: the network data shows scale; the managed-site data shows effectiveness over time. We keep them clearly separated throughout this report.
The Headline Numbers
From the WP Ghost network (last 30 days)
- 100M+ – threat attempts blocked by WP Ghost’s 8G Application Firewall and security rules across the network
- 10M+ – brute force attempts stopped by WP Ghost’s login protection across the network
- 250,000+ – WordPress sites actively protected by WP Ghost
From 10 years of managing WordPress sites at MINBO QRE SRL
- 50%+ — share of unprotected WordPress sites we managed that were compromised at least once over time, before WP Ghost was available as a complete suite
- Up to 90% — drop in bot attacks on default WordPress paths after activating WP Ghost’s Path Security, measured against other security plugins’ logs running on the same sites
- Up to 99% — reduction in total attack attempts observed on properly-configured sites (Ghost Mode + 8G Firewall + Brute Force Protection), with some sites dropping from hundreds of daily attack attempts to 1–3
- Zero — successful compromises on the same managed sites after WP Ghost was deployed with Ghost Mode, Firewall, and Brute Force Protection
For context on why those numbers matter, external research from Patchstack found that the median time from public vulnerability disclosure to mass exploitation is five hours, and that 87.8% of exploits bypass standard hosting defenses. Those findings are why application-layer prevention matters, and they’re part of the reason we measure what we measure.
How We Measure – Methodology
The Data Sources
Source 1: WP Ghost Cloud Telemetry
Sites with Security Threats Log enabled and cloud reporting active send two data points per day to the WP Ghost Dashboard: the date and the total count of threats detected and blocked. No IP addresses, no URLs, no request payloads, no visitor data, no personally identifiable information is ever transmitted. This is documented on the WP Ghost GDPR Compliance page and was designed this way from the start.
Because we retain this data for 30 days before automatic deletion, this report is a rolling 30-day snapshot – not a long-term trend chart. We update the numbers monthly.
Source 2: Our Company-Managed Sites
MINBO QRE SRL has continuously managed WordPress sites since 2016. Over those ten years, we’ve had direct operational access to the full attack history on those sites – before WP Ghost, during WP Ghost’s development, and after deployment. When we say “50%+ of our unprotected sites were compromised over time,” we’re describing our own sites – a case study, not a survey.
Source 3: Comparison Testing Against Other Security Plugins
Before WP Ghost had its own Security Threats Log, we tested WP Ghost alongside other WordPress security plugins (Wordfence, WP Cerber, Solid Security, and others) on the same sites. The comparison numbers on this page come from those other plugins’ logs – we watched their “attack blocked” counters drop after WP Ghost’s Path Security was activated. That’s how we arrived at the “up to 90%” figure on default-path attacks.
What We Can Measure
- Threats caught by the 8G Application Firewall at the PHP level (what reaches the request-inspection layer)
- Brute force attempts on login, password reset, registration, and comment forms
- Security rule triggers (SQLi patterns, XSS patterns, malicious user agents, suspicious request parameters)
- IP addresses blocked by Automated IP Blocking (before they’re banned at the server level)
What We Can’t Measure
This is where most vendor statistics pages fall silent. Ours doesn’t, because the honest answer changes how you interpret the numbers.
Threats blocked by Path Security never get counted. When WP Ghost rewrites /wp-login.php, /wp-admin, /wp-content, /wp-includes, /uploads, /plugins, and /themes, requests to the default paths return 404 at the web server level. The request is rejected before WordPress loads. PHP never starts. The plugin’s logging code never runs. The threat is prevented, but invisibly.
Threats blocked by .htaccess-level firewall rules never get counted. When 8G Firewall rules live in .htaccess (Apache) or the Nginx config, blocked requests never reach the WordPress core. Apache or Nginx rejects the request at the edge. Nothing gets written to the log.
Threats blocked by Automated IP Blocking after the first ban never get counted. Once an IP is banned, subsequent attempts from that IP are blocked at the server level. The first attack gets logged; the next thousand don’t.
This means the real volume of prevented threats is significantly higher than the 100M+ we can measure. The 100M+ figure represents attacks caught at the application firewall layer, after they’ve already made it past path security and edge-level firewall rules. Everything blocked at the server level happens before our measurement tools can see it.
We’re comfortable publishing the measurable number because undercounting is more defensible than overstating. Readers who want to understand the true scale should mentally round up.
The 10-Year Origin Story – Why We Believe the Data
WP Ghost wasn’t built in a boardroom. It was built because the people behind it had been managing WordPress sites for years and kept losing them to automated attacks.
From 2016 onward, the pattern was consistent: sites we managed, company sites, client sites, side projects, kept getting hit. Not targeted attacks. Automated bots running down vulnerability lists. More than half of the unprotected sites we managed were compromised at least once, and several were used for phishing campaigns or flagged by Malwarebytes for distributing malicious content before we could catch them.
Restoring from backup fixed the immediate problem. It didn’t solve the underlying one. The attacks kept coming, same bot behavior, same target paths, same vulnerability databases.
The first version of WP Ghost (released as Hide My WordPress 3) changed /wp-login.php and /wp-admin. It wasn’t a security suite yet. It was an attempt to make our own sites invisible to the scanners we watched probing them daily. Within weeks, attack volume on those sites collapsed.
Between 2016 and 2022, we expanded the plugin to cover every default WordPress path, added the 7G Firewall, brute force protection, and security headers. In 2024–2026, we added 2FA with passkeys, Automated IP Blocking, the Security Threats Log, the GEO Threat Map, and AI Crawler Blocking.
Through all of it, we kept monitoring our own managed sites. The result: after deploying WP Ghost with Ghost Mode, 8G Firewall, and Brute Force Protection, we haven’t had a successful compromise on those sites. Zero. The attack attempts still arrive, they just don’t land.
Customer reports kept matching what we saw internally. That feedback loop is what drove the Security Threats Log and the GEO Threat Map: users kept asking “is WP Ghost actually doing anything?” We built the Threats Log so they could see for themselves.
The “Up to 90%” Measurement – How We Got There
Before WP Ghost had its own Security Threats Log, we ran WP Ghost alongside other popular WordPress security plugins on the same sites. Those other plugins had their own attack logs. We watched what happened to those logs when WP Ghost’s Path Security was turned on.
The pattern was the same every time:
- Before Path Security: other plugins recorded hundreds of bot attacks daily, mostly probes against
/wp-login.php,/wp-content/plugins/,/wp-content/uploads/, and similar default paths - After activating WP Ghost Path Security: attacks on those default paths dropped by up to 90% in the other plugins’ logs
Why? Because automated bots operate on hardcoded target lists. They don’t guess. When /wp-login.php returns 404 at the web server level, the bot’s script fails over to the next site – it doesn’t try alternative paths. The target doesn’t exist as far as the bot is concerned.
This is what Path Security does: it removes the reconnaissance phase that precedes virtually all automated WordPress attacks. It’s also why we treat Path Security as Layer 1 of a defense-in-depth strategy, not as the whole strategy.
The “Up to 99%” Measurement – On Properly Configured Sites
On managed sites where we deployed the full configuration Ghost Mode plus 8G Firewall plus Brute Force Protection, total daily attack volume dropped even further. Sites that previously recorded hundreds of daily attack attempts in their logs dropped to 1–3 attack attempts per day. That’s where the “up to 99%” figure comes from.
The word “up to” matters. Not every site reaches 99%. Sites with higher public profiles, larger attack surfaces, or more third-party integrations see higher residual attack volumes. A personal blog and a 10-million-visitor ecommerce store do not receive the same attention from attackers. But across the managed sites we monitor, the reduction consistently falls in the 87–99% range once the full configuration is deployed.
Why the Network Totals Look the Way They Do
Across the 250,000+ sites running WP Ghost, the 8G Application Firewall blocks more than 100 million threat attempts per month. Of those, more than 10 million are brute force attempts on login, password reset, comments, and registration forms.
Two notes on interpretation:
These are attacks that reached the application firewall. They already survived Path Security (which rejects default-path probes at the server level) and any .htaccess-level firewall rules (which reject malicious requests before PHP loads). The 100M+ number is the volume of attacks that made it past those layers and still got blocked at the application layer.
This is what one month looks like across one security plugin’s network. Patchstack’s 2026 report notes that Wordfence alone blocks “55 million exploit attempts and over 6.4 billion brute force attacks every month” across its own network. Our 100M+ / 10M+ figures are the same kind of industry telemetry: a snapshot of how much automated attack traffic is hitting WordPress sites at any given moment.
The attacks don’t stop. The bots don’t get tired. The 100M+ figure refreshes every 30 days because the attack volume never lets up.
What This Data Doesn’t Prove
Every honest statistics page includes this section.
WP Ghost prevents attacks. It does not:
- Scan your site for existing malware (use Wordfence, Sucuri, or MalCare for that)
- Clean infected sites (use Sucuri’s cleanup service or a specialist)
- Back up your content (use UpdraftPlus, BlogVault, or your host’s backup system)
- Patch vulnerable plugin code (update your plugins regularly)
The “up to 99%” figure is a range, not a guarantee. Individual site results depend on:
- The site’s public profile and visibility
- Which security features are activated (Lite Mode vs Safe Mode vs Ghost Mode; Firewall on/off; Brute Force on/off)
- The plugin and theme stack installed
- Whether the site was already compromised before WP Ghost was deployed
We publish what we can measure and flag what we can’t. The numbers on this page describe network-wide and managed-site patterns, not promises for any individual installation.
How This Data Is Collected – Privacy First
WP Ghost operates under European Union data protection regulations (GDPR). MINBO QRE SRL, the company behind WP Ghost, is registered in Romania.
Network telemetry is opt-in and minimal:
- Only enabled when a site activates the Security Threats Log with cloud reporting
- Only two data points are transmitted per day: the date and the total threat count
- No IP addresses, URLs, request payloads, user data, or personally identifiable information are collected
- Data is automatically deleted after 30 days
- Users can disable cloud reporting at any time from the WP Ghost settings
Full documentation: WP Ghost GDPR Compliance.
Managed-site observations come exclusively from sites that our company owns or has direct managed-services agreements with. No customer data is used in those observations.
Frequently Asked Questions
Does WP Ghost actually prevent hacks?
Based on ten years of data from sites our company manages, yes. Before deploying WP Ghost, more than 50% of our unprotected WordPress sites were compromised at least once over time. After deploying WP Ghost with Ghost Mode, 8G Firewall, and Brute Force Protection, we haven’t recorded a successful compromise on the same sites. Customer reports consistently match that pattern, but individual results vary based on configuration and site profile.
How can you measure “up to 99%” attack reduction?
The 99% figure is a range observed on properly-configured managed sites, Ghost Mode, 8G Firewall, and Brute Force Protection activated together. On those sites, total daily attack volume dropped from hundreds of attempts to 1–3 attempts per day. The “up to” is important: sites with higher public profiles see higher residual volumes. Across managed sites, reductions fall in the 87–99% range.
Is the 100M+ monthly threats number real?
Yes. It’s an aggregated 30-day total from sites with Security Threats Log and cloud reporting enabled. The number reflects threats blocked at the 8G Application Firewall layer. It does not include threats blocked earlier in the chain by Path Security or .htaccess-level rules, because those don’t reach the logging layer. The true prevention volume is higher than what we can measure.
What data does WP Ghost collect?
Only two data points per day per site, and only if cloud reporting is enabled: the date and the total count of blocked threats. No IP addresses, URLs, request content, or user data. Full details on the WP Ghost GDPR Compliance page.
Why does WP Ghost count fewer threats than it actually blocks?
Because most threats are blocked before the measurement layer. Path Security returns 404 at the web server level, WordPress never loads, and the logging code never runs. .htaccess-level firewall rules reject requests before PHP starts. Automated IP Blocking stops repeat offenders at the server level after the first ban. Everything blocked at those earlier layers is prevented but not counted. The 100M+ figure represents attacks that survived earlier layers and got caught at the application layer.
Does path security alone provide real protection?
Measured against other security plugins’ logs, turning on WP Ghost’s Path Security alone produced up to a 90% drop in bot attacks on default paths. The reason is structural: automated bots target hardcoded paths like /wp-login.php and /wp-content/plugins/. When those paths return 404, the bot’s script fails and moves to the next site. Path security is Layer 1 in a defense-in-depth strategy, effective on its own against automated reconnaissance, and most effective when combined with the 8G Firewall and Brute Force Protection.
How does WP Ghost compare to a malware scanner?
They solve different problems. Malware scanners like Wordfence and Sucuri detect and clean malicious files that have already been placed on your site. WP Ghost prevents the attacks that place those files. Think of it as a lock on the door versus a cleanup service for after the break-in. Most sites benefit from running both, prevention plus detection. WP Ghost is officially compatible with Wordfence, Sucuri, Solid Security, Cloudflare, BBQ Firewall, and SiteGround Security.
Why isn’t there a 12-month trend chart on this page?
Because WP Ghost automatically deletes cloud reporting data after 30 days, in line with GDPR principles of data minimization. We refresh the numbers on this page monthly rather than maintaining a long-term dataset. If you want historical trend data on the WordPress attack landscape generally, see our 2025-2026 WordPress Security Statistics report, which aggregates external industry data.
Can I see my own site’s data?
Yes. WP Ghost Premium includes the Security Threats Log (last 30 days of events, with full-text search, CSV export, and filtering) and the Interactive GEO Threat Map (attack origin visualization). The free version shows the last 20 events in the dashboard overview. Your own site’s data is never shared with us beyond the aggregated date+count telemetry you opt into.
Who is behind these numbers?
WP Ghost is developed by MINBO QRE SRL, a software company based in Romania, European Union. The team has continuously developed WordPress security software since 2016. The managed-site observations on this page come from MINBO QRE SRL’s own operational history.
Industry Context
For readers who want to understand why application-layer prevention matters, external research from the WordPress security community:
- 11,334 new WordPress vulnerabilities were recorded in 2025 – a 42% year-on-year increase (Patchstack, Feb 2026)
- Median time from vulnerability disclosure to mass exploitation: 5 hours – the window for patching has collapsed (Patchstack 2026)
- 87.8% of WordPress exploits bypass standard hosting defenses – network firewalls aren’t designed for application-layer threats (Patchstack 2026)
- 72.7% of compromised WordPress sites contain active malware, and 69.6% contain persistent backdoors (Sucuri, 2025)
- Wordfence alone blocks 55M+ exploit attempts and 6.4B+ brute force attacks per month across its network – the baseline attack volume WordPress sites face (Wordfence via TDW Digital, 2025)
Full industry analysis with 43 verified data points: WordPress Security Statistics 2025-2026.
How This Page Is Maintained
- Data window: Last 30 days (GDPR-compliant retention)
- Refresh cadence: Monthly
- Data owner: WP Ghost Team, MINBO QRE SRL
- Methodology changes: Logged in the page’s revision history
We publish what we can verify. When our measurement capabilities expand – for example, if we add threat-type categorization to the Security Threats Log, we’ll update this page to include the new breakdowns, with clear labels for when the methodology changed.