A WordPress security audit is one of those tasks that agencies and site owners postpone until something breaks. Then the cost — in downtime, client trust, and emergency dev hours — makes every skipped audit look like a false economy. This guide breaks down what a real security audit covers, why each layer matters, and what patterns separate sites that get compromised from those that don’t.

Why WordPress Is a Specific Target — Not a Generic One

WordPress powers roughly 43% of all websites on the internet. That scale makes it structurally attractive to attackers: one discovered vulnerability in a popular plugin can be weaponized against millions of sites simultaneously through automated scanning tools. This is not a critique of WordPress as a platform — it is a consequence of market dominance.

The attack vectors are well-documented. According to web security research, the majority of WordPress compromises trace back to three root causes: outdated software, weak credentials, and misconfigured hosting environments. None of these are WordPress-specific flaws. All of them are preventable with a structured audit process.

The practical implication for agencies is that a security audit is not a one-time event triggered by an incident. It is a recurring review cycle — and the frequency should match the complexity and traffic level of each site.

The Core Layers Every WordPress Security Audit Must Cover

A thorough audit touches six distinct layers. Skipping any one of them creates a gap an automated scanner can exploit in minutes.

1. Core, Plugin, and Theme Versions

The most common entry point in compromised WordPress sites is not a sophisticated exploit — it is an unpatched component running a known vulnerability. During an audit, every installed plugin, theme, and the core version itself needs to be checked against the current stable release.

What makes this more complex than it sounds: many agencies manage sites with legacy plugins that are no longer actively maintained. An abandoned plugin sitting at version 2.1.4 while the current release is 3.6.0 is not just outdated — it may contain vulnerabilities that were publicly disclosed in the changelog and are now being actively exploited. The audit should flag not just «needs update» but «maintenance status uncertain» for anything that hasn’t received a commit in over six months.

Deactivated plugins are equally worth reviewing. A deactivated plugin still lives on the server, and its files are still executable. The audit should surface any installed-but-inactive plugins for a deliberate decision: update or delete.

2. User Accounts and Permission Levels

User hygiene is consistently underestimated. A typical agency site accumulates accounts over its lifetime — former clients, freelancers brought in for a specific project, staging users that were never cleaned up. The audit should produce a complete list of all registered users with their assigned roles.

Key checks include: any account with Administrator role that isn’t actively used; any account with a weak or default username like «admin»; and accounts created with temporary email addresses that now return bounce errors. Each of these represents a potential brute-force or account-takeover surface.

Two-factor authentication (2FA) status should also be documented. If 2FA is not enforced for Administrator-level accounts, that is a high-priority finding regardless of password strength.

3. File Permissions and Server Configuration

WordPress runs on a server, and the server’s configuration can either protect it or expose it. During the WordPress security review, file permissions deserve explicit attention. The standard guidance — directories at 755, files at 644, wp-config.php at 440 or 400 — is well established, but it is frequently ignored on shared hosting environments where default configurations are permissive.

The wp-config.php file specifically is a high-value target. It contains database credentials, security keys, and salts. Any audit should verify that direct browser access to wp-config.php is blocked, that its file permissions are correctly restricted, and that its location hasn’t been unnecessarily exposed.

Directory indexing — when a server lists the contents of a directory if no index file is present — should also be disabled. This is a configuration issue at the server level (via .htaccess or nginx config) rather than WordPress itself, but it surfaces consistently during security reviews.

4. Database Security and SQL Injection Surface

The WordPress database contains everything: posts, user data, configuration options, plugin settings. An audit should verify that the database user assigned to WordPress has only the permissions it needs — typically SELECT, INSERT, UPDATE, DELETE — and not broader administrative rights like DROP TABLE or FILE.

Table prefix review is worth including. The default «wp_» prefix is publicly known, and while changing it alone is not a meaningful defense, it does reduce the effectiveness of generic automated injection attempts. Sites still running the default prefix on publicly accessible forms should have this noted.

For sites with custom-built forms or query logic — especially those using direct database calls rather than the WordPress $wpdb abstraction layer — the audit should include a manual or tool-assisted review for SQL injection exposure. This applies particularly to custom plugins or legacy code inherited during a site migration.

5. SSL, HTTPS, and Mixed Content

HTTPS is not optional in 2026. But having an SSL certificate installed does not guarantee a clean security posture. Mixed content issues — where a page served over HTTPS loads resources (scripts, stylesheets, images) over plain HTTP — can expose session cookies and undermine the protection that HTTPS is supposed to provide.

The audit should confirm: the SSL certificate is valid and not approaching expiration; HSTS headers are configured; HTTP to HTTPS redirects are in place and cover all subdomains; and a mixed-content scan has been run on key pages. Tools like a browser’s developer console or dedicated scanner can surface mixed content that isn’t visible at the page level.

6. Login Security and Brute-Force Protection

The WordPress login page is the most attacked surface on any WordPress site. Automated bots run credential-stuffing attacks continuously against default login URLs. An audit should document:

• Whether the login URL has been changed or obscured
• Whether login attempt limiting is active and configured correctly
• Whether CAPTCHA or honeypot fields are in place on login and registration forms
• Whether XML-RPC is disabled or rate-limited (it provides an alternative authentication endpoint frequently targeted for brute force)
• Whether application passwords are restricted for accounts that don’t need them

These controls work in combination. None of them alone is sufficient, but together they raise the cost of automated attacks high enough that bots move on to easier targets.

Tools That Support a WordPress Security Audit

No audit should rely entirely on manual inspection. Several tools are useful for different layers of the review.

WPScan is the industry-standard vulnerability scanner for WordPress. It queries a continuously updated database of known vulnerabilities against the plugins, themes, and core version installed on a site. Running WPScan as part of a routine audit surfaces publicly known issues that might otherwise be missed during a manual check.

Sucuri SiteCheck performs an external scan — checking for malware signatures in publicly accessible files, flagging blocklist status, and identifying obvious configuration issues visible from outside the server.

Wordfence operates from inside the WordPress installation. Its malware scanner compares core files against known-clean checksums, which makes it effective at detecting file modifications — a key indicator of a compromised installation.

These tools are complementary, not substitutes for each other. An external scan won’t catch a backdoor injected into a theme file. An internal scanner won’t identify that a plugin’s version is on the CVE list. Combining both, alongside manual review of users and server configuration, produces a more complete picture.

What a Security Audit Report Should Actually Contain

The output of a WordPress security audit is only as useful as the decisions it enables. A raw list of findings is not a report — it is noise.

A well-structured security audit report should categorize findings by severity (critical, high, medium, low), provide context for why each finding matters, and recommend a specific remediation action — not just «update plugins» but which plugin, to what version, and what the known vulnerability is.

For agencies delivering security audits as part of a managed WordPress service, this level of specificity is what builds client trust. A client who sees a clear finding labeled «XML-RPC enabled — allows brute-force bypass of login rate limiting — recommend: disable via plugin or server configuration» understands the risk and the fix. A client who sees «security issues detected» understands nothing and builds no confidence in the process.

The report should also document what was checked but found acceptable — this is often skipped but is important for demonstrating thoroughness and for creating a repeatable baseline for future audits.

How Often Should a WordPress Security Audit Run

Frequency depends on site complexity, traffic, and what’s at stake. A useful framework:

• Quarterly: Standard for most agency-managed sites. Catches accumulated drift in user accounts, plugin versions, and configuration changes.
• After major changes: Any new plugin installation, theme update, or server migration should trigger a focused review of the affected layer — not a full audit necessarily, but a targeted check.
• After a security incident: A full forensic audit is required, not just remediation of the immediate symptom. Compromised sites frequently have multiple entry points, and addressing only the visible one leaves the others open.
• Before site handoffs: When an agency takes over management of a site previously maintained by another provider, a security audit should be the first technical action — before any other work is done on the site.

Common Findings That Get Missed

After running security audits across dozens of WordPress sites, a few findings appear consistently and consistently get underestimated:

Debug mode left on in production. WP_DEBUG set to true logs errors to a publicly accessible file (debug.log). That log frequently contains database error messages, file paths, and configuration details that are useful to an attacker mapping the site’s structure.

Outdated security keys and salts. WordPress uses security keys in wp-config.php to secure cookies. If these have never been regenerated — particularly after a suspected compromise or a staff change — they should be refreshed as part of the audit.

Staging sites without authentication. Agencies frequently set up staging environments that mirror production. If that staging environment is publicly accessible without HTTP authentication, it exposes the same codebase and sometimes the same data, without the production site’s hardening measures applied.

Backup files left on the server. Manual backups — database dumps, zip archives of the entire site — are sometimes left in the webroot. These are indexed by search engines, accessible to anyone, and contain everything an attacker needs to reconstruct the site offline and look for exploits.

None of these require advanced technical knowledge to find. They require a structured checklist and the discipline to run through it consistently — which is exactly what a repeatable security audit process provides.

The Business Case for Regular Security Audits

For agencies, the argument for building WordPress security audits into standard service delivery isn’t primarily technical — it’s operational. A compromised client site costs more to remediate than the audit that would have prevented it. Emergency incident response, SEO recovery from blocklist entries, client communication, and potential liability exposure all add up quickly.

Beyond risk reduction, recurring security audits create a defensible record of due diligence. In industries where clients handle sensitive user data — healthcare, legal, finance — that documentation has real value. It demonstrates that security is a managed process, not a reactive one.

According to the fundamentals of cybersecurity practice, the majority of successful breaches exploit known vulnerabilities — not zero-days. That means most successful attacks against WordPress sites are preventable with standard audit hygiene. The gap is not technical capability — it’s process consistency.