
the wordpress security baseline everyone skips
wp core verify-checksumsthe wordpress baseline nobody sets up until after they get hacked
here's the thing about wordpress. it runs something like 40% of the internet, which means it's also the single biggest target on the internet. most of those hacks don't come from some genius exploiting a zero day in wordpress core. they come through plugins. old, abandoned, never-updated plugins that someone installed in 2019 for a feature they forgot about.
the good news is you don't need a security team to fix this. you need five commands and ten minutes a month. let's go through the actual baseline.
step 1: check if core files have been tampered with
wordpress core ships with known checksums for every file. if an attacker drops a backdoor into one of those files, or modifies one to call home, this command will catch it.
wp core verify-checksums
run this from your site root with wp-cli installed. if it comes back clean, great. if it flags mismatches, don't panic, but don't ignore it either. compare the flagged files against a fresh download of the same wordpress version. if something's been injected, that's your sign to restore from a known-good backup and rotate every credential tied to that site.
step 2: find out which plugins are the weak link
plugins are the attack surface. most wordpress compromises trace back to a plugin that was outdated, abandoned, or just poorly coded. this command gives you a clean list of what needs attention.
wp plugin list --update=available
anything that shows up here is a plugin running on an old version with a known fix available. the longer it sits unpatched, the longer you're running code with a public changelog telling attackers exactly what's broken. that's not theoretical, that's literally how automated scanners work. they read changelogs for the word "security" and go hunting for sites still on the old version.
step 3: audit who actually has admin access
this one gets skipped constantly. people set up a site, give a contractor or an old employee admin access, and never revoke it. an unused admin account with a weak or reused password is a wide open door.
wp user list --role=administrator
go through that list like it's a guest list at your house. recognize every name? good. don't recognize one, or recognize a name that shouldn't still have keys? remove it or demote it to a lower role immediately. while you're in there, check for admin accounts with generic usernames like "admin" or "support", those get brute-forced constantly because they're the first guesses.
step 4: shut off the php editor in the dashboard
wordpress lets admins edit plugin and theme php files directly from the dashboard by default. that's convenient until an attacker gets into an admin account, or a plugin vulnerability gives them that same access. at that point, the built-in editor becomes a built-in way to drop a backdoor without ever touching ftp or ssh.
turn it off. add this to your wp-config.php file:
define('DISALLOW_FILE_EDIT', true);
this one line removes an entire category of post-compromise persistence. it won't stop someone from getting in, but it stops them from using the dashboard itself as the weapon once they're there.
step 5: actually patch your plugins, monthly, not "eventually"
once you know what's outdated, update it. and then do it again next month. and the month after that. security isn't a one time setup, it's a habit.
wp plugin update --all
put this on a calendar reminder or a cron job with a staging site in front of it so an update doesn't break your live site unexpectedly. either way, make it routine. the sites that get compromised aren't usually the ones that never patch, they're the ones that patched once and called it done.
the takeaway
none of this requires a security budget or a specialist. it requires wp-cli, ten minutes, and the discipline to actually run it on a schedule instead of only after something breaks. check your core files, audit your plugins, review your admin list, lock the editor, patch monthly. save this, send it to whoever runs your site, and make it part of how the site gets maintained, not a one time fire drill.