Why Some WordPress Sites Keep Getting Hacked (And What to Do About It)

Introduction: The Hacking Cycle That Shouldn’t Happen

If your WordPress site has been hacked once, you cleaned it, and now it’s been hacked again — you’re not alone. We see this pattern frequently. A site gets compromised, the owner removes the obvious malware or restores from a backup, and within weeks the same symptoms return. That cycle is frustrating, but it’s also predictable. Most of the time, the root cause was never addressed.

Security plugins and patchwork fixes treat symptoms. They remove infected files, block an IP for a day, and make the dashboard feel protected. But if the actual vulnerability — the door the attacker walked through — is still open, you’re just delaying the next incident. This article walks through the most common structural reasons sites get hacked repeatedly and the operational fixes that stop it for good.

Vulnerability #1: Stale Core, Plugins, and Themes

The single most common entry point for attackers is outdated software. WordPress core releases include security patches for known vulnerabilities. So do plugin and theme updates. When you skip those updates — even for a few weeks — your site is running with published exploits that automated bots scan for constantly.

A concrete example: an old version of a popular contact form plugin had a file upload vulnerability that let attackers upload a PHP shell to the server. That plugin was patched, but thousands of sites never applied the update. Bots scanned for the specific file path, uploaded a backdoor, and had persistent access. That wasn’t a sophisticated attack — it was a script checking for a known weakness.

Why do site owners skip updates? Common reasons include fear of breaking the site, lack of a staging environment, or simply not knowing an update is available. None of these are bad reasons, but they’re operational problems that need solutions: automated managed updates, staging sites, or at minimum a regular update schedule with a tested backup strategy.

Fix it: Enable automatic updates for core security releases. Use a managed update service or schedule a recurring monthly maintenance window. Before updating, confirm you have a reliable backup. If you’re on a shared host, use a plugin that provides safe update rollbacks.

Vulnerability #2: Weak or Reused Credentials

Brute force attacks and credential stuffing are not exotic. Attackers have databases of usernames and passwords leaked from other breaches. If your admin account uses a common password, or if you reuse passwords across services, those databases are your vulnerability.

Credential stuffing works because people reuse passwords. An attacker takes the email/password combo from a breached forum and tries it on thousands of WordPress admin login pages. If the username is “admin” (still shockingly common) and the password matches the breach, they’re in. It doesn’t require any exploit — just the credentials you gave away elsewhere.

Fix it:

• Never use the default “admin” username. Create admin accounts with unique names.
• Enforce strong passwords for all users, especially editors and administrators.
• Require two-factor authentication (2FA) for all admin logins. Plugins like Wordfence or two-factor are straightforward to configure.
• Use a password manager. It generates and stores unique passwords so you never have to reuse one.

These steps don’t require developer skills. They require discipline. Once configured, they block the vast majority of credential-based attacks automatically.

Vulnerability #3: Loose File Permissions and Ownership

File permissions control who can read, write, and execute files on your server. Misconfigured permissions are a common reason sites stay compromised after initial cleanup. An attacker who gains limited access can write to folders that should be read-only, planting permanent backdoors.

The standard permission model for WordPress is straightforward:

• Directories: 755 — owner can write, everyone else can read and execute.
• Files: 644 — owner can write, everyone else can read.
• wp-config.php: 600 or 640 — only the owner (and web server) can read it. This file contains your database credentials and security keys. If it’s set to 644 or 755, anyone who reaches the file via a URL or directory traversal can read your database password.

What happens when permissions are too loose? An attacker can upload a PHP file to your uploads directory, then execute it directly via the web. That file becomes a backdoor that your security scanner might not flag because it looks like a valid upload. The only way to prevent that is to make sure the uploads directory cannot execute PHP — which requires a server configuration change.

Fix it:

• Review your file permissions using your hosting cPanel or a plugin like WP File Permissions Check.
• Set directories to 755 and files to 644 as a baseline.
• Lock down wp-config.php to 600 or 640.
• Add a php.ini or .htaccess rule to disable PHP execution in the wp-content/uploads directory. This alone prevents many common upload-based attacks.

If you’re unsure how to do this, your hosting provider’s support can usually check permissions for you. It takes five minutes and closes a door that stays open on most compromised sites.

Vulnerability #4: No Web Application Firewall (WAF)

A Web Application Firewall (WAF) sits between your site and incoming traffic. It inspects every request and blocks known attack patterns before they reach your WordPress installation. Without a WAF, your server processes every request — including automated SQL injection attempts and cross-site scripting payloads.

There are two types of WAF for WordPress:

• Cloud-based WAF (e.g., Cloudflare, Sucuri). Traffic is routed through the provider’s network. The WAF blocks malicious requests before they reach your server. This is generally more effective because it stops attacks before they hit your hosting resources.
• Server-level WAF (e.g., ModSecurity, or a plugin-based WAF like Wordfence). The request reaches your server first, then the WAF inspects it and drops malicious traffic. This works but uses your server’s CPU and bandwidth.

For high-risk sites — e-commerce, membership, or sites handling user data — a cloud-based WAF is not optional. It also provides rate limiting, IP blacklisting, and DDoS protection. For smaller sites, a plugin-based WAF is better than nothing, but you should understand the tradeoff in server load.

Fix it:

• Implement a cloud-based WAF if your site processes payments or sensitive data.
• If you use a security plugin with WAF features, ensure it’s configured to block known exploit patterns (most have this on by default).
• Whitelist legitimate IPs for admin access if your team works from fixed locations.

Operational Checklist: Your Post-Hack Recovery Plan

If your site has been hacked and you need to recover, do not just restore a backup and hope. Follow this checklist to ensure the vulnerability is closed and the site is clean.

1. Scan your site with a reputable security plugin or server-level scanner. Look for suspicious files in uploads and themes directories.
2. Quarantine the infection. Remove infected files or restore from a clean backup dated before the hack.



3. Change all passwords — admin accounts, FTP, database, and hosting control panel. Use unique, strong passwords.
4. Enable 2FA for every admin user before allowing them back into the dashboard.
5. Update everything — WordPress core, all plugins, and all themes. Replace any nulled or abandoned plugins with supported alternatives.
6. Audit user accounts. Remove unknown users and downgrade unused admin accounts to subscriber or editor roles.
7. Review file permissions as described above. Lock down wp-config.php and disable PHP execution in uploads.
8. Check for backdoors. Look for unexpected admin accounts, strange cron jobs, or outbound traffic from your server.
9. Implement a WAF to block repeat attacks.
10. Document the incident. Note the likely entry point and what you changed. This becomes a reference for future maintenance.

This is not a quick fix — expect to spend several hours on a thorough cleanup. But it prevents recurrence. Skipping any step leaves the door cracked.

When to Call in the Pros

DIY recovery works for straightforward cases. But some situations go beyond what a single site owner can handle:

• Your site is a large WooCommerce store with hundreds of user accounts and customer data.
• The infection keeps returning despite a clean restore and updated credentials.
• You don’t have a clean backup, and you’re trying to piece together a working site from infected files.
• The attack involved server-level access beyond WordPress (e.g., compromised SSH keys, database injection via hosting).
• You don’t have time for a multi-hour recovery and need the site back up reliably.

Managed WordPress security services handle this full-time. They have the tools to scan for deeply buried backdoors, isolate infected environments, and harden the server against future attacks. They also provide ongoing monitoring, which is the only way to catch the early signs of a compromise before it turns into a full-blown defacement or data leak.

If your business depends on the site — and most do — the cost of a professional recovery is almost always less than the cost of downtime and reputation damage.

Final Thought: Security Is a Process, Not a Plugin

One security plugin cannot fix weak passwords, out-of-date code, loose file permissions, and the absence of a firewall. It can scan for known malware and log login attempts, but it cannot architect a secure operational setup for you. That has to be built — and maintained — at the server and workflow level.

The sites that stop getting hacked are the ones where someone takes ownership of security as an ongoing process. Updates are applied regularly. Permissions are checked after migrations. Passwords are rotated. Logs are reviewed. It’s not glamorous work, but it’s the difference between spending your day fighting infections and spending it running your business.

Proactive defense isn’t a one-time project. It’s a commitment to maintenance that never stops. But once your site is hardened, the attacks that do come in will be blocked before they ever reach your dashboard. And that peace of mind is worth the effort.