WordPress security audit: what a 2026 audit must check, and how to hire for one

A WordPress security audit tells you whether your site is already compromised, what it is exposed to, and whether you could recover if it were hacked tonight. In 2026 the scope grew: WordPress core itself was exploited, attacks began on the day of a patch, and nearly half of plugin flaws arrived with no fix. This guide sets out what a current audit must check, the commands you can run yourself, and how to judge a provider.

What a WordPress security audit is

A WordPress security audit is a structured check of everything an attacker could use to get into your site, plus a search for signs that someone already has. It ends in a written report that ranks what to fix first. It is not the same as running a scanner plugin, which checks one layer and cannot see your server, your accounts or your backups.

A good audit answers four questions:

1. Is the site already compromised?
2. Which known vulnerabilities is it exposed to right now?
3. How easy is it to break in through logins, permissions and server settings?
4. If the worst happened tonight, could you recover?

Why 2026 changed what an audit must cover

The 2026 numbers moved several items from "nice to check" to "must check". Each is sourced in our WordPress security statistics.

An audit quote that does not mention core version checks, the database, or PHP is working from an older playbook.

The full audit checklist

This is the scope we would expect from any competent audit. Use it to compare quotes, or work through it yourself.

1. Compromise checks

• Core files compared against official checksums.
• PHP files in wp-content/uploads, which should contain none.
• Unknown administrator accounts and recently created users.
• Injected options, rogue scheduled tasks and unexpected autoloaded data in the database.
• Spam pages indexed under your domain, including cloaked pages only Google sees.
• Indicators named in current advisories, such as the files reported for CVE-2026-87902.

2. Known vulnerability exposure

• WordPress version against the latest security release for its branch.
• Every plugin and theme, active or not, against a vulnerability database.
• Plugins abandoned by their authors. Our WordPress statistics found 46.4% of directory plugins not updated in over two years.
• Premium plugins with expired licences.
• PHP and database versions against their support dates.

3. Access and configuration

• Number of administrators, and whether each one needs that role.
• Two-factor authentication on admin accounts.
• Login rate limiting, and whether XML-RPC is needed.
• File permissions and file editing in the dashboard (DISALLOW_FILE_EDIT).
• Settings in wp-config.php that disable automatic updates.
• Debug output and exposed files such as backups or phpinfo pages in the web root.
• HTTPS, security headers and the host's firewall.
• Hosting, SFTP, database and DNS accounts: who has access, and whether former staff or contractors still do.

4. Recovery readiness

• Backups stored off the server, on a schedule.
• A test restore, timed.
• Uptime monitoring and who gets the alert.
• A written plan for who to call if the site is hacked.

Checks you can run yourself

If you have SSH and WP-CLI, these cover a large part of sections 1 and 2 in a few minutes. Run them on a copy if you are unsure.

# 1. core version and integrity
wp core version
wp core verify-checksums

# 2. plugins and themes, with available updates
wp plugin list --fields=name,status,version,update_version,auto_update
wp theme list --fields=name,status,version,update_version

# 3. administrators
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

# 4. PHP in uploads (should return nothing)
find wp-content/uploads -name '*.php'

# 5. recently changed PHP files, last 14 days
find . -name '*.php' -mtime -14 -not -path './wp-content/cache/*'

# 6. scheduled tasks
wp cron event list

# 7. settings that block updates
grep -nE "AUTOMATIC_UPDATER_DISABLED|WP_AUTO_UPDATE_CORE|DISALLOW_FILE_MODS|DISALLOW_FILE_EDIT" wp-config.php

# 8. PHP version used by the site
wp eval 'echo PHP_VERSION, PHP_EOL;'

Anything unexpected from checks 1, 3, 4 or 6 means you should stop treating this as an audit and start treating it as an incident. Follow how to fix a hacked WordPress site. A quick non-technical version of these checks is in our WordPress security checklist.

What these commands cannot tell you: whether a plugin has an unpatched flaw (you need a vulnerability database), whether Google sees spam pages that you do not, and whether your backups actually restore.

What you should receive

The report is the product. Ask to see a sample before you agree to pay.

Be wary of any audit that promises a site will be "unhackable" or "100% secure". No honest provider can promise that. What an audit can do is remove known, fixable weaknesses and tell you what is left.

Questions to ask before you hire

1. What exactly is in scope? Files only, or the database, server settings and accounts too?
2. Do you need server access, or only an admin login? Admin-only audits cannot check core integrity properly.
3. Which vulnerability database do you check plugins against?
4. Do you check for existing compromise, or only for weaknesses?
5. Will you fix what you find, and is that priced separately?
6. If you find malware, what happens next? Cleanup should be a clear next step, not a surprise invoice.
7. Will you work on a copy of the site, or on live?
8. How is access handled and removed afterwards?

Our guide to hiring a WordPress developer covers contracts and access in more depth.

How often to audit

An audit is a snapshot. Its value fades as soon as the next plugin vulnerability is published, which, at Patchstack's 2025 rate of 11,334 a year, averages more than one an hour. Ongoing maintenance is what keeps the result true. That is the argument in is WordPress maintenance worth it.

What an audit costs

We do not publish a fixed audit price, because the work depends on the site: a ten-page brochure site with eight plugins is a different job from a store with sixty plugins and custom code. We quote a fixed scope after a short look. Under our care plans, which our pricing page says are "typically about 15 to 20 percent of the build cost per year", an onboarding review of versions, plugins, backups and security is part of starting the plan, as described on our maintenance and support page.

When you compare quotes from different providers, compare the scope against the checklist above, not just the price.

Checklist: before the auditor starts

• Take a full backup of files and database and store it off the server.
• Gather access: WordPress admin, hosting panel, SFTP or SSH, and DNS.
• List who else has access, including past developers and agencies.
• Note anything odd you have seen: slow pages, strange redirects, spam emails from your domain, Search Console warnings.
• Note any premium plugins and where their licences are held.
• Decide who will approve fixes, and by when.