Why WordPress sites get compromised: outdated software, weak credentials, risky plugins, weak hosting, and supply-chain tricks, plus fixes that reduce real risk.
Topics Firewalls & scanners
Updated Published
WordPress made publishing easy. Plugins made it flexible. That same flexibility is why vulnerabilities show up so often in real incidents: not because core is uniquely fragile, but because sites run a lot of third-party code and leave known gaps open.
This is a practical map of common causes and what to do about them. Live lookups: WordPress vulnerabilities database. Hardening path: security hardening guide.
Cleanup when those show up: WordPress malware removal.
Old core releases miss security fixes that are already public. Enable automatic updates for minor/security releases where you can, and schedule major updates after a quick staging check.
Fix: Keep core current. Do not run “vintage” versions because a plugin “likes” them. Replace that plugin instead.
Strong code does not save a reused admin password. Brute-force and credential stuffing still work on boring blogs.
Fix: Unique passwords, 2FA, few administrators, and the habits in the login security guide. Use SFTP/SSH keys where possible instead of shared FTP passwords.
Shared neighbors, neglected servers, and unsupported PHP versions expand risk outside the WordPress admin. Hosts that never mention isolation, backups, or patch cadence are a gamble.
Fix: Modern PHP, a host that patches, account isolation when you run multiple sites, and backups you have restored once.
Plugins and themes are independent PHP packages. Many are solid. Some ship bugs. Some stop getting updates while sites keep running them. Industry reports over the years have consistently pointed at extensions (not only core) as a large share of compromises. Treat every install as code you must maintain. Deep dive: plugins as security risks and how to tell if a plugin is secure.
Typical failure modes inside vulnerable plugins:
Fix: Install from trusted sources, update promptly, remove unused extensions, and replace abandoned ones. Watch advisories in the vulnerabilities database.
A well-known historical example: older Contact Form 7 releases had a critical unrestricted file upload issue (fixed in later versions). Popularity did not prevent the bug; updating did. The lesson is not “never use forms.” It is “known CVEs require patches, not hope.”
Some attacks skip your coding mistakes entirely. They ship a useful-looking plugin or “nulled” theme with a hidden backdoor. Once installed, the payload phones home or creates admin access. See plugin supply chain.
Fix: No nulled premiums. No random ZIP mirrors. Prefer wordpress.org or the vendor site. After any odd install, audit users, cron, and new PHP under uploads.
Anyone can publish PHP that hooks into WordPress. Core gets heavy scrutiny. A niche plugin used by 8,000 sites may not. Reviews on wordpress.org catch a lot of malware, but they do not rewrite every line for secure coding, and they do not maintain the plugin for the author.
Your job as a site owner is narrower: fewer plugins, known sources, current versions, and a plan when a CVE drops.
uploads)wp-config.php secret keys)Site-wide checklist: WordPress security checklist. Login surface: login security complete guide.
No stack is unhackable. Most WordPress breaches still come from postponed updates, weak access, and extensions nobody is watching. Close those three and you remove a large share of real-world risk.
Found this useful? Share it.