The key takeaway: the overwhelming majority of WordPress hacks trace back to a small set of well-understood vulnerabilities — outdated plugins and themes, weak admin credentials, SQL injection in vulnerable code, cross-site scripting, and exposed XML-RPC endpoints — each with a specific, known fix rather than a vague "improve security" recommendation.
Why WordPress Is Such a Common Target
WordPress powers a large share of all websites — W3Techs has consistently tracked it at over 40% of the entire web for several years running. That scale is exactly why it's targeted: a single vulnerability discovered in a popular plugin can potentially be exploited across tens of thousands of sites still running the vulnerable version, making automated, mass-scanning attacks worth an attacker's time in a way that a custom-built site rarely justifies.
This is important context because it reframes the problem correctly: WordPress core itself isn't the weak point in most attacks. The plugin and theme ecosystem around it is, along with basic configuration choices that are entirely within a site owner's control.
Outdated Plugins and Themes
Security research consistently finds that outdated plugins and themes with publicly disclosed vulnerabilities are the single largest attack vector for WordPress compromises — far ahead of core vulnerabilities or targeted, custom attacks. Once a vulnerability is publicly disclosed (even when a patch is already released), automated scanners begin probing the web for sites still running the vulnerable version within hours.
The fix is straightforward but requires discipline: enable automatic updates for plugins and themes where possible, remove any plugin that's no longer actively maintained (check its "last updated" date in the WordPress plugin directory), and check the vulnerability history of new plugins before installing them via a database like WPScan's vulnerability database.
Weak or Reused Admin Credentials
Brute-force login attempts against wp-login.php are constant background noise on the web — automated bots try common username/password combinations against any WordPress site they find, and a weak or reused password turns that background noise into an actual breach.
The fix: enforce strong, unique passwords for every admin account, enable two-factor authentication, rename or restrict access to the default "admin" username if it's still in use, and limit login attempts to slow down automated brute-force tools.
SQL Injection in Vulnerable Plugins
SQL injection lets an attacker manipulate a database query through a plugin's own input field — a contact form, a search box, a URL parameter — that doesn't properly sanitize what's typed into it, potentially exposing or altering the entire WordPress database including user credentials.
The fix is largely the same as for outdated plugins: SQL injection vulnerabilities are almost always found in specific plugin versions and patched quickly once reported, so staying current on updates closes the vast majority of these holes before they're ever exploited on a given site.
Cross-Site Scripting (XSS)
XSS lets an attacker inject malicious JavaScript into a page through an unsanitized input field, which then runs in the browser of anyone who visits that page — potentially stealing admin session cookies or redirecting visitors to a malicious site. Comment fields, contact forms, and plugin settings that don't escape user input are the most common entry points.
The fix: the same update discipline applies, since XSS vulnerabilities are typically plugin-specific and patched quickly; a web application firewall (included in many security plugins) adds a layer that can block known XSS injection patterns even before a patch is applied.
XML-RPC Abuse
WordPress's XML-RPC interface, originally built for remote publishing tools, has become a common vector for two specific attacks: brute-force login attempts routed through the pingback method to evade normal rate-limiting, and using a site's XML-RPC endpoint as an amplifier in DDoS attacks against other targets.
The fix: disable XML-RPC entirely unless the site actively depends on a plugin (most commonly Jetpack) or a mobile app that requires it — for most sites, this closes off an attack surface with no functional downside.
Insecure File Permissions
Overly permissive file and folder permissions — often left at their default or loosened during troubleshooting and never reset — let an attacker who gains any foothold on the server modify core files, plant a backdoor, or read sensitive configuration data like database credentials in wp-config.php.
The fix: WordPress's own documentation recommends 644 for files and 755 for directories as a secure baseline, with wp-config.php ideally locked down further since it holds database credentials directly.
Quick Reference Table
| Vulnerability | Common Entry Point | Primary Fix |
|---|---|---|
| Outdated plugins/themes | Known, disclosed CVEs | Enable auto-updates, remove unmaintained plugins |
| Weak admin credentials | wp-login.php brute-force | Strong passwords, 2FA, login attempt limiting |
| SQL injection | Unsanitized plugin input fields | Keep plugins updated to patched versions |
| Cross-site scripting (XSS) | Comment/contact form fields | Update plugins, use a web application firewall |
| XML-RPC abuse | Pingback brute-force, DDoS relay | Disable XML-RPC if not actively needed |
| Insecure file permissions | Server-level misconfiguration | 644 for files, 755 for directories |
A Practical Hardening Checklist
- Update everything on a schedule, not reactively — WordPress core, every plugin, and the active theme, ideally with automatic updates enabled for minor releases.
- Remove unused plugins and themes entirely, not just deactivate them — an inactive but installed plugin with a known vulnerability can still be exploited in some attack chains.
- Enforce two-factor authentication for every account with publishing or admin-level access, not just the primary admin account.
- Disable XML-RPC unless a specific, actively used integration requires it.
- Test security changes on a staging copy first, since hardening steps like permission changes or disabling features can occasionally break a plugin that depends on them.
Staying Informed About New Vulnerabilities
Vulnerability databases like WPScan and Patchstack track newly disclosed WordPress plugin and theme vulnerabilities as they're published, and many security plugins pull from these same sources to alert site owners when an installed plugin has a known issue. Subscribing to one of these feeds, rather than waiting to notice a problem after the fact, is the difference between patching within hours of disclosure and patching after an automated scanner has already found the hole.
Common Mistakes That Lead to Compromise
- Assuming a security plugin alone is sufficient, when it can't retroactively patch a known vulnerability in outdated software still running on the site.
- Deactivating rather than deleting unused plugins, leaving known-vulnerable code present on the server even if it isn't actively running.
- Reusing the same admin password across multiple client sites, turning a single leaked credential into a multi-site breach.
- Ignoring file permission hardening because it's a one-time setup task rather than a recurring maintenance item.
- Restoring from an old backup without checking whether it also restores a since-patched vulnerability, undoing a previous fix without realizing it.
Wrapping Up
In short, the vulnerabilities that actually compromise WordPress sites are a well-documented, predictable set — outdated plugins and themes above all, plus weak credentials, SQL injection, XSS, XML-RPC abuse, and loose file permissions — each with a specific, known fix rather than a vague call to "be more secure." Consistent updates and a handful of concrete hardening steps close off the overwhelming majority of real-world attacks, which is exactly the scanning and documentation work our Erdo CRA Compliance plugin is built to help track alongside broader EU compliance requirements.