WordPress powers 43% of the web[1]. That makes it the biggest target on the internet. Every day, bots scan millions of WordPress sites looking for known vulnerabilities, weak passwords, and outdated plugins. Most of them find what they’re looking for.

If you run a WordPress site and haven’t actively thought about security, your site is probably already compromised, you just don’t know it yet. Most WordPress hacks don’t announce themselves. They inject hidden links, redirect mobile visitors to spam sites, or quietly mine cryptocurrency using your server resources. The site looks normal to you. It looks very different to Google.

The plugin problem is a security problem

I’ve written before about the WordPress plugin problem, how every plugin adds complexity, maintenance burden, and potential conflicts. But from a security perspective, the picture is even worse.

Every plugin is a potential entry point. In 2025, over 7,000 WordPress plugin vulnerabilities were reported, up 34% from 2024[2]. Not theme vulnerabilities. Not core WordPress vulnerabilities. Plugin vulnerabilities. The code that you or your developer installed because you needed a contact form, a slider, a booking calendar, or an SEO tool.

The most dangerous plugins aren’t the obscure ones with 50 installations. They’re the popular ones with millions of installations that become high-value targets. When a vulnerability is found in a plugin with 5 million active installations, hackers have a window of hours to days before most sites update, and automated scripts scan the entire internet for vulnerable installations within minutes of a vulnerability disclosure.

In January 2026, a critical vulnerability in a popular WordPress form plugin affected over 6 million sites. Within 48 hours, security firms detected active exploitation on over 200,000 sites. The patch was available within 24 hours. But most sites don’t auto-update plugins. Most site owners don’t check for updates daily. The average time to apply a critical plugin update on self-managed WordPress sites? 26 days.

Twenty-six days of having a known, actively exploited vulnerability on your business website.

Brute force attacks: simple, relentless, effective

A brute force attack is exactly what it sounds like: automated scripts trying thousands of username/password combinations per hour against your login page. It’s not sophisticated. It doesn’t need to be.

The default WordPress login URL is /wp-admin or /wp-login.php. Every bot on the internet knows this. If you haven’t changed it, your login page is being hammered right now, I guarantee it. Check your server logs. You’ll find hundreds or thousands of failed login attempts per day from IPs around the world.

If your admin username is “admin” and your password is anything shorter than 16 random characters, your site will eventually be brute-forced. Not “might be.” Will be. It’s a mathematical certainty given enough time and enough automated attempts.

Basic protections that every WordPress site should have: rename the login URL, limit login attempts (lock out IPs after 5 failed tries), enforce strong passwords, enable two-factor authentication for all admin accounts. These four steps eliminate 95% of brute force risk (according to Sucuri’s threat research[3]). Almost no self-managed WordPress site has all four in place.

The update treadmill

WordPress core releases security patches regularly. Plugins release updates when vulnerabilities are found (if they’re still maintained, abandoned plugins never get patched). Themes need updating too. PHP versions need updating. Server software needs updating.

On a typical WordPress business site with 15-20 plugins, there are updates available almost every week. Each update needs to be tested, because updates can break things. A plugin update might conflict with your theme. A PHP update might break an older plugin. A WordPress core update might change how an API works, breaking a custom integration.

This is why “just keep everything updated” is bad advice without a system. Updates need to be: applied promptly (not 26 days later), tested in a staging environment first, rolled back quickly if something breaks, and monitored after deployment.

Most business owners don’t have this system. Most freelance developers don’t maintain it either, they built the site and moved on. The site slowly falls behind on updates, vulnerabilities accumulate, and eventually something gets exploited.

What happens when your WordPress site gets hacked

The consequences range from annoying to catastrophic:

SEO spam injection: Hackers inject hundreds of hidden pages selling pharmaceuticals, gambling services, or counterfeit goods. Google indexes these pages, associates your domain with spam, and your legitimate pages drop in rankings. Recovering from an SEO spam attack takes 3-6 months even after cleanup.

Malware distribution: Your site starts serving malware to visitors. Google flags it with a “This site may harm your computer” warning. Traffic drops to zero overnight. Your customers receive warnings about your business.

Data theft: If your site collects any customer data, contact forms, email subscriptions, payment information, that data is now in the hands of criminals. In the EU, this triggers GDPR notification requirements. You have 72 hours to notify your supervisory authority and potentially every affected customer[4].

Cryptomining: Your server resources are hijacked to mine cryptocurrency. Your site becomes slow, your hosting bill increases, and you have no idea why until someone investigates the server.

Defacement: The most visible but least common. Your homepage is replaced with a political message or a hacker’s calling card. At least this one you notice immediately.

The average cost of recovering from a WordPress hack for a small business: €500-2,000 for cleanup, plus the incalculable cost of lost traffic, lost customers, and damaged reputation during and after the incident.

What “managed security” actually means

When managed hosting providers talk about security, they should mean a specific set of protections, not just marketing language. Here’s what real managed WordPress security includes:

Web Application Firewall (WAF): A firewall specifically designed for web applications that filters malicious requests before they reach WordPress. It blocks known attack patterns, SQL injection attempts, cross-site scripting, and file inclusion attacks at the server level, before your site even processes the request.

Proactive plugin and core updates: Updates applied within hours of release, not days or weeks. Tested in staging first. Rolled back if anything breaks. This closes the vulnerability window from 26 days to under 24 hours.

File integrity monitoring: Continuous scanning that compares your WordPress files against known-good versions. If a core file, plugin file, or theme file is modified unexpectedly, an alert fires immediately. This catches compromises that malware scanners miss.

Daily malware scanning: Both signature-based (looking for known malware) and behavioral (looking for suspicious code patterns). Not the plugin-based scanning that runs inside WordPress, server-level scanning that can’t be disabled by the malware itself.

Login hardening: Two-factor authentication, IP whitelisting for admin access, automatic lockouts, CAPTCHA on login, and hidden or renamed login URLs, all configured by default, not left to the site owner to set up.

Backup and recovery: Daily automated backups stored off-server, with tested recovery procedures. When prevention fails, and eventually, statistically, something will get through, the ability to restore a clean version in minutes rather than hours or days.

SSL/TLS management: HTTPS isn’t optional in 2026, it’s a ranking factor[5] and a legal requirement for any site handling personal data in the EU. Managed security includes SSL certificate provisioning, renewal, and monitoring.

The DIY security trap

I see this constantly: business owners install a security plugin (usually Wordfence or Sucuri) and assume they’re secure. These plugins are good. But they’re running inside WordPress, which means if WordPress itself is compromised, the security plugin can be disabled or bypassed.

It’s like putting a security guard inside a building with no locks on the doors. The guard is useful, but the guard can be overpowered. Security needs to start at the perimeter, the server level, not at the application level.

Plugin-based security also adds performance overhead. Wordfence, for example, scans every request against its rule set using PHP, the same PHP that’s serving your pages to visitors. On shared hosting, this can add 200-500ms to every page load. You’re trading speed for security, and getting neither at an acceptable level.

A realistic security checklist for 2026

If you manage your own WordPress security (or want to verify that whoever manages it is doing a competent job), here’s the minimum:

WordPress core: latest version, auto-updates enabled. Plugins: all updated, unused plugins deleted (not just deactivated, deleted), no plugins abandoned by their developers. Themes: only the active theme installed, updated, no unused themes. PHP: version 8.2 or later[6]. SSL: active, properly configured, auto-renewing. Backups: daily, stored off-server, tested at least quarterly. Login: not at /wp-admin, rate-limited, 2FA for all admin users. Passwords: 16+ characters, unique, stored in a password manager. User accounts: only accounts that need to exist, with the minimum role required. File permissions: 644 for files, 755 for directories, wp-config.php at 440.

If you read that list and felt overwhelmed, you understand why managed security exists. It’s not that any single item is complicated, it’s that the sum of all items, maintained consistently over time, is a part-time job. And most business owners have an actual job to do.

At Fork IT, every site we build and host includes managed security as standard. Not because we’re paranoid, because we’ve cleaned up enough hacked sites to know that prevention is cheaper, faster, and less stressful than recovery. And because our reputation is tied to the sites we manage. If your site gets hacked on our watch, that’s our failure, and we treat it that way.

Sources

  1. W3Techs – WordPress Usage Statistics – WordPress market share and usage data.
  2. Patchstack – State of WordPress Security in 2025 – Annual report on WordPress plugin vulnerabilities and security trends.
  3. Sucuri – Website Threat Research Report – Data on brute force attacks and common WordPress attack vectors.
  4. GDPR Article 33 – Notification of a personal data breach – 72-hour breach notification requirement to supervisory authority.
  5. Google Search Central – HTTPS as a Ranking Signal – Google’s confirmation of HTTPS as a search ranking factor.
  6. WordPress.org – PHP Compatibility and WordPress Versions – Official PHP version recommendations for WordPress.