WordPress Security Audit: Complete Checklist for 2026

A WordPress security audit is a systematic review of your entire site - server configuration, access controls, software, database, and file integrity - to identify vulnerabilities before attackers find them.

Whether you manage your own WordPress site or oversee one for your organization, this checklist walks you through every layer of a proper security audit. You can use it as a self-assessment or hand it to a developer as a starting point. We also cover what automated scans miss and when a professional assessment is worth the investment.

What Is a WordPress Security Audit?

A WordPress security audit is a comprehensive review of your website's security across every layer, from the server environment to the application code to user access patterns.

Unlike a plugin scan that checks files against a database of known malware signatures, a security audit examines how your site is configured, who has access to what, and where vulnerabilities might exist, even in code that isn't technically malicious.

Think of it this way: a malware scan is like checking whether someone has already broken into your house. A security audit examines whether your locks work, your windows latch properly, and whether you've accidentally left a spare key under the mat.

When to schedule a WordPress security audit:

• When taking over a site from another developer or agency
• After any security incident or suspicious activity
• Before a major launch or redesign
• After significant plugin or theme changes
• As an annual or quarterly checkup for any site that matters to your organization

The Complete WordPress Security Audit Checklist

This checklist covers the six areas that a thorough WordPress audit should examine. Work through each section systematically. If any item fails or you're unsure how to check it, flag it for follow-up.

WordPress Core, Themes, and Plugins Review

The foundation of any WordPress security audit starts with the software running on your site. Outdated or abandoned software is one of the most common entry points for attackers.

• Verify WordPress core is up to date. Go to Dashboard > Updates and confirm you're running the latest stable release. WordPress core updates patch known vulnerabilities, and delaying them leaves your site exposed.
• Check that WordPress core files haven't been modified. Use WP-CLI (wp core verify-checksums) or a file integrity plugin to compare your core files against official checksums. Modified core files can indicate a compromise or a poorly implemented customization.
• Update all themes to their latest versions. Navigate to Appearance > Themes and check for available updates. Remove any themes you're not actively using - inactive themes still contain executable code.
• Update all plugins to their latest versions. Go to Plugins > Installed Plugins and install any available updates. Check the "Last Updated" date on the WordPress.org listing for each plugin.
• Identify abandoned plugins. Any plugin that hasn't been updated in over a year is a risk. Check the plugin's WordPress.org page or changelog for recent activity. If the developer has stopped maintaining it, find an alternative or remove it.
• Cross-reference plugins against vulnerability databases. Search your plugins on WPScan's vulnerability database or Patchstack to check for known security issues. Even current versions may have unpatched vulnerabilities.
• Remove deactivated plugins entirely. Deactivated plugins still sit on your server and can be exploited. If you're not using a plugin, delete it - not just deactivate.
• Review plugin configurations. A security plugin running on default settings may provide less protection than you expect. Verify that each plugin's security-relevant settings are properly configured.

User Access and Authentication

User management is where many WordPress sites fail their audit. Over time, sites accumulate accounts that no longer need access, and permissions that were meant to be temporary become permanent.

• Audit every user account. Go to Users > All Users and review every account. Can you identify the person behind each one? If not, investigate before removing.
• Remove or downgrade unnecessary accounts. Former employees, contractors who finished their projects, and test accounts should be removed. If someone only writes blog posts, they should be an Author or Editor, not an Administrator.
• Enforce the principle of least privilege. Every account should have the minimum permissions required for its role. Review WordPress roles (Administrator, Editor, Author, Contributor, Subscriber) and confirm each user is assigned appropriately.
• Enable two-factor authentication for all admin accounts. 2FA adds a critical second layer beyond passwords. Use an authenticator app rather than SMS where possible. Plugins like WP 2FA or Wordfence can enforce this.
• Audit password strength. Require strong passwords for all user roles. Check whether your site enforces password complexity or allows users to set weak passwords.
• Review login activity. Check for signs of credential stuffing or brute force attempts. Look for failed login patterns, successful logins from unusual locations, or accounts logging in at unexpected times. An activity log plugin like WP Activity Log can surface this data.
• Check whether user registration is appropriately restricted. Go to Settings > General and verify that "Anyone can register" is only enabled if your site requires public registration. If it is enabled, confirm the default role is set to the lowest privilege level.

Server and Hosting Configuration

This is where plugin-based security fundamentally falls short. WordPress plugins operate within the application layer. They cannot examine the server environment in which WordPress runs.

• Verify your PHP version. Check your hosting panel or use phpinfo() to confirm your server runs a currently supported PHP version. PHP versions that have reached the end of life no longer receive security patches. As of 2026, PHP 8.1 and earlier versions are end of life.
• Review file permissions. Directories should be set to 755, files to 644, and wp-config.php should be 600 or 640. Permissions set to 777 (world-writable) are a serious vulnerability. Check permissions via your hosting file manager or SFTP client.
• Confirm wp-config.php is protected. This file contains your database credentials and security keys. Verify it's not accessible via a web browser by visiting yourdomain.com/wp-config.php - you should see a blank page or an error, not your configuration.
• Check for directory listing. Visit yourdomain.com/wp-includes/ in your browser. If you see a list of files instead of a 403 Forbidden error, directory listing is enabled and needs to be disabled in your server configuration or .htaccess file.
• Verify SSL/TLS is properly configured. Your entire site should load over HTTPS. Check for mixed content warnings, and verify your SSL certificate is current and not expiring soon. Use a tool like SSL Labs to test your TLS configuration for weaknesses.
• Confirm backups are running and restorable. Verify that automated backups are active, check the most recent backup date, and confirm backups are stored offsite (not just on the same server as your site). Most importantly, test whether a backup can actually be restored.
• Check for exposed error logs or debug files. Files like debug.log, error_log, or php_errors.log in publicly accessible directories can leak sensitive information about your server and application. Verify these are either disabled or protected from public access.
• Review .htaccess for security rules. Your .htaccess file should block access to sensitive files (like wp-config.php and .htaccess itself), prevent script execution in upload directories, and disable directory browsing.

Database Security

Your WordPress database contains content, user credentials, configuration settings, and potentially sensitive customer or member information. A compromised database can expose everything.

• Check the database table prefix. If your tables still use the default wp_ prefix, they're slightly easier to target with SQL injection attacks. While changing the prefix alone isn't a strong defense, it's a basic hardening step worth noting.
• Review database user privileges. The database user configured in wp-config.php should have only the privileges WordPress requires (SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, DROP, INDEX). It should not have GRANT or SUPER privileges.
• Check for sensitive data stored in plain text. Review whether custom plugins or forms are storing sensitive information (payment data, personal details) in the database without encryption. WordPress core handles password hashing correctly, but custom code may not.
• Verify the database is not externally accessible. Your database should only accept connections from localhost or your specific server IP. Remote database access should be disabled unless specifically required and properly secured.

File Integrity and Malware Analysis

Plugin-based malware scanners check files against signatures of known threats. A proper audit goes deeper to identify modifications, backdoors, and obfuscated code that automated scanners miss.

• Verify WordPress core files against official checksums. Use WP-CLI (wp core verify-checksums) to check whether any core files have been modified. Unauthorized changes can indicate a compromise.
• Scan the uploads directory for executable files. The /wp-content/uploads/ directory should contain only media files (images, PDFs, documents). PHP files or scripts in this directory are a strong indicator of a backdoor. Check for .php, .phtml, or other executable file extensions.
• Look for obfuscated code in theme and plugin files. Obfuscated code - long strings of encoded characters, base64-encoded content, or eval() statements - is rarely legitimate. Review recently modified files in your theme and plugin directories for suspicious patterns.
• Check for unauthorized file modifications. Review the modification dates on the theme and plugin files. If files were modified outside of normal update cycles, investigate. Pay particular attention to functions.php, wp-config.php, and .htaccess.
• Scan for known malware signatures. Run a malware scan using a reputable tool (Wordfence, Sucuri SiteCheck, or your hosting provider's scanner). A clean scan result is a baseline, not a guarantee; it confirms that no known threats were found.
• Verify no unauthorized cron jobs exist. Check wp-cron.php activity and any server-level cron jobs. Attackers sometimes install persistent cron jobs that re-infect a site or send spam on a schedule.

Firewall and Access Control

A web application firewall is only effective if it's properly configured. Many sites have a WAF installed, but configured so permissively that it blocks almost nothing.

• Verify your WAF is active and properly configured. If you're using a plugin-based WAF (Wordfence, Sucuri) or a DNS-level WAF (Cloudflare, Sucuri DNS), confirm it's actively filtering requests and not running in "learning" or "monitor only" mode.
• Review firewall rules and blocking patterns. Check which attack types are being blocked (SQL injection, cross-site scripting, file inclusion). Review the firewall logs to confirm it's actually intercepting threats.
• Check rate limiting settings. Rate limiting prevents brute force attacks and bot abuse. Verify that login attempt limits are configured and that aggressive request patterns are being throttled.
• Review bot protection. Check whether your site differentiates between legitimate bots (search engine crawlers) and malicious bots (scrapers, vulnerability scanners). A properly configured bot management system blocks the bad while allowing the good.
• Check IP blocking and geographic restrictions. If your site doesn't serve a global audience, consider whether geographic restrictions make sense. Review any IP allowlists or blocklists to ensure they're up to date.
• Verify XML-RPC is disabled or restricted. The XML-RPC endpoint (xmlrpc.php) is a common target for brute force attacks and DDoS amplification. Unless you specifically need it for mobile apps or remote publishing, disable or restrict access to it.

What Plugin Scans Miss: The Case for Professional Audits

The checklist above covers what you can assess on your own, and it's a solid starting point. But here's what we've learned after 14 years of managing WordPress security across 200+ sites: plugin-based scans and self-assessment checklists have significant blind spots.

Security plugins serve a purpose. They can detect known malware, block obvious brute force attempts, and provide a basic firewall. But they operate entirely within WordPress. They cannot examine the server environment, evaluate the quality of custom code, or recognize attack patterns that don't match known signatures.

We regularly encounter sites where owners have installed multiple security plugins - sometimes four or five - each one adding overhead and complexity while creating a false sense of protection. The login page has been moved to /my-secret-login. The database uses a custom prefix. An activity log faithfully records every failed login attempt. And yet the site remains vulnerable because the actual attack surface was never examined.

Where professional expertise goes beyond the checklist:

• Server-level blind spots. Plugins operate within WordPress; they cannot audit the server WordPress runs on. Hosting misconfigurations, exposed ports, outdated server software, and improper PHP configurations are invisible to any WordPress plugin. Many of the security incidents we investigate trace back to server-level issues.
• Custom code vulnerabilities. If your site uses custom themes, plugins, or integrations, those code paths aren't covered by any vulnerability database. A professional audit reviews custom code for SQL injection, cross-site scripting, insecure data handling, and other application-level vulnerabilities.
• Attack pattern analysis. Experienced security professionals recognize indicators of compromise that automated tools miss. Unusual file modification timestamps, subtle changes to core files, suspicious cron jobs, and traffic patterns that suggest reconnaissance all require human expertise to interpret.
• Configuration context. A checklist can tell you whether your file permissions are correct. A professional can tell you whether your entire security configuration makes sense as a system - whether the pieces work together or leave gaps between them.

Seeing a brute force attack in your logs is interesting. Stopping it before it reaches your server is a security measure. A clean malware scan doesn't mean your files haven't been tampered with - it means they haven't been tampered with in a way the scanner recognizes.

What You Should Receive from a Security Audit

Whether you perform a self-assessment using the checklist above or hire a professional, a proper WordPress security audit produces more than a pass/fail grade. You should receive:

• An executive summary that non-technical stakeholders can understand, explaining your overall security posture and the most critical issues in plain language.
• Detailed findings listing each vulnerability identified, its severity (critical, high, medium, low), and supporting evidence.
• Prioritized recommendations indicating what needs immediate attention versus what can be addressed over time.
• Verification steps explaining how to confirm that remediation was successful and vulnerabilities have been closed.

This documentation also serves as the foundation for completing vendor security questionnaires - formal assessments from IT departments, insurance companies, or upstream partners that evaluate your organization's security practices.

DIY Checklist vs. Professional Assessment

The checklist in this guide covers what you can assess yourself. For many sites, working through it systematically and addressing any failures provides meaningful security improvement.

Where professional assessment adds value is in server-level configuration, identifying vulnerabilities in custom code, understanding attack patterns and how they apply to your specific site, and having the experience to distinguish "normal" from indicators of compromise.

A self-assessment works well for: basic brochure sites with limited traffic and no sensitive data; sites using only well-known plugins and themes with no custom code; and organizations with in-house technical staff who can act on findings.

A professional audit is worth the investment for any site that handles donations, member data, or e-commerce transactions, organizations in regulated industries, sites that serve as critical infrastructure, and any site recovering from or concerned about a compromise.

How Often Should You Audit Your WordPress Site?

For most sites, an annual security audit provides a reasonable baseline. Quarterly assessments make sense for high-traffic sites, organizations in sensitive industries, or any site that handles financial transactions.

Beyond scheduled audits, you should assess security after any incident or suspicious activity, before major launches or redesigns, after significant changes to plugins or themes, and whenever you take over a site from another developer or agency.

What Happens After the Audit?

Identifying vulnerabilities is only valuable if they get fixed. After an audit, remediation should be prioritized based on severity and exploitability. Critical issues that could lead to immediate compromise need immediate attention. Lower-severity findings can be scheduled into regular maintenance.

If active malware or a breach is discovered during the audit, immediate hack recovery and remediation becomes the priority before continuing with broader security improvements.

Once remediation is complete, verification confirms the vulnerabilities are actually closed. Ongoing monitoring ensures new issues are caught before they become incidents.

For many organizations, a security audit reveals that maintaining WordPress security in-house requires more ongoing attention than they can realistically provide. That's often the point where ongoing security services become more practical than periodic audits.

Why FatLab Builds Security Into Hosting

Here's the thing about security audits: they identify problems, but they don't prevent them. You can audit your site, fix everything, and six months later face the same vulnerabilities because the underlying infrastructure hasn't changed.

That's why we took a different approach.

Rather than selling audits as a standalone service, we built comprehensive security into every hosting plan. When you move to FatLab, everything a security audit would check is already handled.

Server-level malware scanning with Imunify360 runs continuously - not daily or weekly scans, but real-time monitoring that detects and quarantines threats immediately.

Our Cloudflare Enterprise WAF filters malicious traffic before it reaches your server, blocking SQL injection, cross-site scripting, and brute-force attacks at the network edge. DDoS protection, rate limiting, and bot management are included by default.

Every site gets a proper SSL configuration across all layers. File permissions are set correctly from the start. PHP versions stay current. Backups run daily with 30-day retention and are stored offsite. Our weekly SafeUpdates process keeps WordPress, themes, and plugins up to date by testing before deployment.

When we onboard a new client, we're essentially performing a security audit: reviewing the site's current state, identifying issues, and remediating them as part of the migration. The difference is that those protections remain in place permanently, managed by our team rather than on you to maintain.

We've protected sites for organizations where security isn't optional.

Club for Growth, one of the most visible political advocacy organizations in the country, has trusted us with their mission-critical infrastructure for over a decade - through election cycles, media spikes, and targeted attacks. Their sites have experienced no slowdowns or outages because the security infrastructure was designed to handle such scenarios.

Our AI-powered monitoring adds another layer, analyzing patterns across our entire client base to identify threats before they become incidents. When something suspicious happens, our team investigates - not just an automated alert that lands in your inbox for you to figure out.

Stop Wondering Whether Your Site Is Secure

If you're reading this article, you probably have some concerns about your WordPress site's security. Maybe you've had a scare. Maybe you're just not sure whether those plugins are actually doing anything. Maybe you're tired of wondering.

You have two options.

You can work through the checklist above, fix what you find, and then take on the ongoing responsibility for maintaining that security posture - keeping plugins up to date, monitoring for new vulnerabilities, responding to incidents, and managing backups.

Or you can move to infrastructure where all of that is already handled, where security isn't something you audit periodically but something that's built into every layer of how your site operates, where a team of WordPress specialists is watching your site around the clock, not just sending you alerts but actually responding to threats.

View our security-included hosting plans starting at $99/month, or schedule a free consultation to discuss your specific security concerns.

We'll tell you honestly whether your current setup makes sense or whether there are gaps that need addressing - no obligation, no pressure.

Your website supports your organization's mission. It shouldn't keep you up at night.

Frequently Asked Questions

What is a WordPress security audit?

A WordPress security audit is a systematic review of your entire website's security posture. It examines your server configuration, WordPress core and plugin versions, user access controls, database security, file integrity, and firewall settings to identify vulnerabilities before attackers exploit them. Unlike a malware scan that only checks for known threats, a security audit evaluates how your site is configured and where weaknesses exist.

How long does a WordPress security audit take?

A thorough security audit typically takes several hours to a full day, depending on the site's complexity, the number of plugins, and the amount of custom code. The audit itself is non-disruptive - your site remains fully operational throughout the process.

Will a security audit break anything on my site?

A properly conducted audit is read-only during the assessment phase. Changes only occur during remediation, and any modifications should be tested before deployment. At FatLab, we test all changes in staging environments before deploying to production.

What if malware is found during the audit?

If active malware is discovered, quarantine and remove it immediately rather than waiting for the full audit to complete. The audit then continues to identify how the malware entered and what vulnerabilities enabled the compromise.

How often should you audit WordPress security?

For most sites, an annual WordPress security audit is a reasonable baseline. Quarterly audits make sense for high-traffic sites, organizations that handle sensitive data, or any site processing financial transactions. You should also run an audit after any security incident, before major launches, and whenever you take over a site from another developer.

How much does a WordPress security audit cost?

Professional WordPress security audits typically range from $500 to several thousand dollars, depending on the site's complexity, the depth of the assessment, and the auditor's experience. At FatLab, we take a different approach: comprehensive security is built into our managed hosting plans starting at $99/month, so your site is continuously monitored and protected rather than assessed at a single point in time.

How is this different from ongoing security services?

A security audit is a point-in-time assessment - a snapshot of your current security posture. Ongoing security services provide continuous protection: real-time monitoring, immediate threat response, regular updates, and proactive defense. Think of audits as diagnosis and ongoing services as treatment and prevention.

Can you audit a site you don't host?

Yes, security audits can be performed on sites hosted anywhere. However, some server-level checks may be limited by the hosting provider's access. Full server configuration review requires appropriate access levels.

What's the difference between a vulnerability scan and a security audit?

A vulnerability scan is automated and checks for known issues against a database of signatures. A security audit is comprehensive and includes manual review, configuration assessment, access control analysis, and expert evaluation of your overall security posture. Scans find known problems; audits find problems scanners miss.