Securing WordPress

WordPress is not insecure. Unmaintained WordPress is insecure. The distinction is entirely about process.

The controls that actually prevent incidents

Almost every compromised WordPress site we have looked at shares one of a small number of causes: an unpatched plugin, a weak or reused administrator credential, no file-integrity monitoring, or a backup that had never been test-restored.

Hardening checklist

• Patching cadence with an owner and a deadline, not best intentions
• Least-privilege roles; no shared administrator accounts
• Two-factor authentication enforced for every editor and above
• File-integrity monitoring with alerts that someone reads
• Backups stored off-host, with a documented and rehearsed restore
• Login rate limiting and an allowlist for administrator access where possible
• Disable file editing in the dashboard and XML-RPC if unused

Detection beats prevention alone

Assume a plugin will eventually ship a vulnerability. What determines the damage is how quickly you notice. Alert on unexpected file changes, new administrator users, and outbound traffic patterns, not just uptime.

When something has already happened

Isolate, preserve evidence, rotate every credential including database and API keys, and rebuild from known-good rather than cleaning in place. Cleaning in place leaves the persistence mechanism behind more often than not.