By framework
WordPress security — why it's targeted and the minimum defenses
WordPress is the most targeted because of its share — via plugin/theme vulnerabilities, skipped updates, weak admins, and exposed admin surfaces (wp-admin/xmlrpc). The minimum defenses: automatic updates, minimal plugins, strong auth (2FA), limited admin exposure, and backups. Defensive, no attack steps.
For: anyone running a WordPress site. No attack steps here — just why it's targeted and the minimum defenses. For the cross-framework picture, see the security-by-framework hub.
Why it's targeted: the entries are predictable
Attacks on WordPress aren't magic — automated brute-forcing probes a fixed set of weaknesses. Know the entries and you know where to close.
① Plugin/theme vulnerabilities
Known holes in third-party code. The biggest entry. Left unattended or abandoned, the hole stays open.
② Skipped updates
Unapplied core/plugin patches. Automated tools hit published CVEs.
③ Weak/reused admins
admin + weak password + no 2FA. Taken over via login brute-force or leaked-password reuse.
④ Exposed admin surface
wp-admin/xmlrpc/REST user enumeration. A stepping stone for brute-force or amplification.
The minimum defenses (5 steps)
Close WordPress's specific pitfalls in order. Each is done in the admin panel or config.
Automate updates (top priority)
Keep plugins/themes minimal
Strong auth (2FA) for admins
admin, and keep privileges minimal. (→ what 2FA is)Limit admin exposure and login attempts
xmlrpc.php if unused, and suppress REST-API user enumeration. Restricting where the admin panel can be reached from is even better.Backups and tamper detection
Common (dangerous)
- core and plugins updated manually, then left
- unused plugins/themes merely deactivated
- admin
admin+ weak password + no 2FA - login attempts, xmlrpc, user enumeration left wide open
Correct
- core/plugins/themes on automatic updates
- unused extensions deleted to minimize
- admins on strong password + 2FA, least privilege
- login-attempt limits, unneeded features off, recoverable backups
This site's view: manage 'extensions and neglect,' not the core
What works for WordPress isn't flashy config but the operational discipline of "don't over-add extensions, don't leave them unattended." Plugins are convenient, but each one adds a "responsibility to keep updating." This site's principle is the same as for any technology: minimize dependencies (plugins), automate updates, and defend with strong auth and recoverable backups. It looks WordPress-specific but is really the universal foundation applied. You can check plugin CVEs with the CVE/KEV lookup.
Read next
- Hub: security by framework · Laravel security
- Foundation: the vulnerability-response playbook · backup essentials
- Auth: what 2FA is · Glossary: what phishing is (the top route to admins)
FAQ
QIs WordPress dangerous?
WordPress core is actively maintained and isn't especially vulnerable in itself. What's dangerous is usage. Its largest-share status makes it an easy target for automated attacks, and most real break-ins come not from the core but from third-party plugin/theme vulnerabilities, skipped updates, weak admin accounts, and exposed admin surfaces. The flip side: closing those cuts most of the risk.
QHow many plugins is too many?
The rule is 'only the minimum you need.' Each plugin widens the attack surface, and any one that's left unupdated or abandoned becomes a hole. Before installing, check update frequency, adoption, and last-updated date; and for anything you don't use, delete it rather than just deactivating (deactivated files can still be a vulnerability target). The same goes for themes.
QWhat's the bare minimum I should do?
(1) Enable automatic updates for core, plugins, and themes; (2) delete unused plugins/themes to cut the count; (3) give admin accounts a strong password and two-factor authentication (2FA); (4) limit admin (wp-admin/login) exposure and login attempts; (5) keep recoverable offline backups plus tamper detection. These five stop most automated attacks.