A security audit isn’t a one-time event. It’s a structured review of every layer where your WordPress site can be compromised. With 7,966 new WordPress vulnerabilities discovered in 2025 alone (a 34% increase over the prior year), the question isn’t if your site has exposure. It’s where.
What is a WordPress security audit?
A security audit systematically evaluates your WordPress installation against known attack vectors. You’re checking configurations, reviewing access controls, validating that updates are applied, and confirming that your hosting environment isn’t leaving doors open. The goal is finding vulnerabilities before automated bots do.
Most WordPress hacks aren’t targeted. They’re automated scans hitting millions of sites looking for known plugin vulnerabilities, default credentials, and misconfigured file permissions. WordPress powers 43% of all websites. That makes it the single biggest target for automated attacks, which hit WordPress sites roughly every 39 seconds.
Why do WordPress sites get hacked?
The breakdown is stark and hasn’t changed much in five years:
- 90% of vulnerabilities come from plugins. The average business site runs 20-30 plugins. Each one is a potential entry point maintained by a different developer with different security practices.
- 6% come from themes. Especially nulled (pirated) themes that ship with backdoors pre-installed.
- 4% are in WordPress core. The core team patches quickly, but sites that delay updates remain exposed.
The strategic implication: your plugin decisions are your security decisions. Every plugin you add increases your attack surface. Every plugin you remove reduces it. An audit forces you to confront that tradeoff honestly.
The 12-point security audit checklist
Work through these in order. Each builds on the previous one.
1. Core, plugin, and theme updates
Check that WordPress core, all plugins, and your active theme are running their latest versions. Log into wp-admin and check the Updates page. For a CLI approach: wp core check-update && wp plugin list --update=available && wp theme list --update=available. Flag any plugin that hasn’t been updated in 12+ months. That’s a plugin its developer has likely abandoned.
2. Remove unused plugins and themes
Deactivated plugins can still be exploited if their files are accessible. Delete anything you’re not actively using. Keep only your active theme and one default theme (Twenty Twenty-Four) as a fallback.
3. User account review
List all admin-level users: wp user list --role=administrator. Remove any you don’t recognize. Check for accounts with weak usernames like “admin” or “test.” Verify that every admin account uses a unique, strong password and has two-factor authentication enabled.
4. File permissions
Correct permissions for a WordPress installation: directories at 755, files at 644, wp-config.php at 600 or 640. Check with: find /path/to/wp -type d -not -perm 755 and find /path/to/wp -type f -not -perm 644. The uploads directory should never contain PHP files. Search for them: find wp-content/uploads -name "*.php".
5. Database security
Confirm your database user has only the privileges WordPress actually needs (SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, DROP, INDEX). No GRANT or SUPER privileges. Change the default wp_ table prefix on new installations. For existing sites, check that database credentials in wp-config.php aren’t reused elsewhere.
6. SSL/HTTPS configuration
Every page should load over HTTPS with no mixed content warnings. Check your certificate expiry date. Verify that HTTP requests redirect to HTTPS with a 301 (not a 302). Test with: curl -I http://yourdomain.com and confirm the Location header points to the HTTPS version.
7. Security headers
Check these headers are present in your server response:
- Strict-Transport-Security (HSTS) — forces HTTPS for all future visits. Minimum:
max-age=31536000; includeSubDomains - X-Content-Type-Options: nosniff — prevents MIME-type sniffing attacks.
- X-Frame-Options: SAMEORIGIN — blocks clickjacking via iframes.
- Content-Security-Policy — controls which resources the browser can load. Start with report-only mode to avoid breaking things.
Test your headers at securityheaders.com or with curl -I https://yourdomain.com.
8. Login hardening
Limit login attempts (fail2ban at the server level is more reliable than plugins). Disable XML-RPC if you don’t need it: it’s a common brute-force vector. Consider moving wp-login.php to a custom URL, but know this is security through obscurity, not a real defense. The real defense is strong passwords plus 2FA.
9. Backup verification
Having backups isn’t enough. Verify they actually restore. Download your latest backup, spin up a staging environment, and confirm the site works. Check backup frequency matches your content update cadence. A site updated daily needs daily backups. Store backups offsite (not on the same server as the site).
10. File integrity monitoring
Compare your core files against the official WordPress release: wp core verify-checksums. Do the same for plugins: wp plugin verify-checksums --all. Any modified file is either a customization you made intentionally or evidence of compromise. Know which is which.
11. Malware scanning
Run WPScan against your site to check for known vulnerabilities: wpscan --url https://yourdomain.com --api-token YOUR_TOKEN. Use Sucuri SiteCheck for a quick external scan. For deeper inspection, grep your theme and plugin files for common malware patterns: base64_decode, eval(, $_REQUEST in unexpected places.
12. Monitoring and alerting
Set up uptime monitoring so you know immediately if your site goes down. Configure file change alerts for critical files (wp-config.php, .htaccess, theme files). Review your access logs weekly for unusual patterns: spikes in 404s hitting wp-login.php, requests to files that don’t exist, or traffic from unexpected geographic regions.
Tools for running your own security audit
You don’t need a security firm to run a basic audit. These tools cover most of the checklist above:
- WPScan CLI — open-source vulnerability scanner specifically for WordPress. Free API tier covers most small sites.
- Sucuri SiteCheck — free external scanner that checks for malware, blacklisting, and known vulnerabilities.
- securityheaders.com — instantly grades your HTTP security headers.
- Query Monitor plugin — shows database queries, hooks, and HTTP requests happening on each page load. Useful for spotting suspicious activity from plugins.
- WP-CLI — the
wp core verify-checksumsandwp plugin verify-checksumscommands catch file modifications without installing any additional plugins.
How often should you audit?
Full 12-point audit: quarterly. Quick checks (updates, user accounts, backup verification): monthly. Automated scanning (WPScan, uptime monitoring): continuous.
Run an immediate audit after any of these events: a plugin update that changed major versions, a hosting migration, adding a new admin user, or discovering that a plugin you use has a published CVE. Don’t wait for the quarterly schedule when something material changes.
What to do if you find a vulnerability
Severity determines your response speed. A vulnerable plugin with a published exploit? Remove or update it within hours, not days. A missing security header? Important but not an emergency. Prioritize by exploitability.
If you find evidence of active compromise (modified core files, unknown admin users, suspicious PHP in uploads), the response is different. Take the site offline, restore from a clean backup, change all credentials (database, SFTP, WordPress admin, hosting panel), and investigate how the attacker got in. Then fix that vector before bringing the site back online.
For ongoing protection, our security consulting service includes quarterly audits, real-time monitoring, and incident response. We handle the architecture so you can focus on running the business without worrying about the next vulnerability disclosure.