Auditing a WordPress Site in 30 Minutes

WordPress is the world's most popular CMS and also its most popular ransomware-entry point. The combination of huge install base, plugin ecosystem of variable quality, and admins who set the site up once and never log in again means that any random sampling of wp-content/ paths on the public internet will turn up something exploitable in minutes. If you've inherited a WordPress estate and want to know whether to be worried, this is the half-hour audit.

Step 1: identify the version and the surface (5 min)

Every WordPress install leaks its version unless someone has explicitly hardened it. The fastest tells:

• <meta name="generator" content="WordPress 6.x" /> in the page source
• ?ver=6.x.x query strings on wp-includes/js/* and wp-content/plugins/*/style.css URLs
• The exact paths of plugin assets in the HTML — each plugin slug tells you what's installed without you having to query /wp-admin/

Match the version against the vulnerability database. WordPress core itself is usually patched (auto-updates have been on by default since 5.6), but the plugins are where the issues live. Note every plugin slug you see and look each one up.

Step 2: configuration tells (10 min)

Several configuration choices are diagnostic and visible from outside:

/wp-login.php accessible without rate-limiting. Try three obviously bad passwords and watch the response. If you don't get rate-limited or shown a CAPTCHA after the third, the site has no brute-force protection — which means admin/Welcome1 and editor/password123 will work somewhere.

XML-RPC enabled at /xmlrpc.php. XML-RPC supports system.multicall, which lets one HTTP request try 1,000 password combinations. If /xmlrpc.php returns "XML-RPC server accepts POST requests only" instead of 404, the brute-force attack surface is 1,000x larger than the login page.

Directory listing on /wp-content/uploads/. If you get an Apache index of files instead of 403, the attacker can browse every file ever uploaded. This sometimes includes draft documents, customer data, and backup .sql dumps from a plugin that helpfully wrote them there.

readme.html accessible. It contains the exact core version. Not a vulnerability by itself, but a strong signal that nobody has done any hardening at all — which means the rest of the install probably has every default it shipped with.

Step 3: the plugin sweep (10 min)

This is where 80 % of WordPress vulnerabilities live. For each plugin slug you collected in step 1:

• Look up the version (often in readme.txt at the plugin root, accessible without auth)
• Check whether there are known vulnerabilities at that version or earlier
• Check whether the plugin has been updated in the last 12 months (abandoned plugins are a flashing red light, even with no known CVE)

Special attention to: anything that handles file uploads, anything with "form" in the name, anything that talks to e-commerce APIs, and anything bundled by the hosting provider that "just works." The bundled ones are often customised forks that don't receive upstream patches.

Step 4: the easy fixes (5 min to write up)

After the audit, the high-impact low-cost fixes are almost always:

1. Update core and every plugin to current.
2. Remove plugins not used in the last 90 days. Each one is attack surface that pays you nothing.
3. Force strong passwords on every admin/editor account. Run the existing password hashes (if you have DB access) through a quick check.
4. Add a WAF or login-rate-limit plugin if there isn't one.
5. Disable XML-RPC unless something specifically needs it.
6. Set DISALLOW_FILE_EDIT in wp-config.php so a compromised admin account cannot rewrite plugin PHP from the dashboard.

Doing this without manual probing

The full sweep is fast enough to do by hand, but it is faster — and reproducible across an estate of 30 sites — with tooling. Our WordPress scanner does steps 1 through 3 in one pass and outputs a per-site checklist. Pair it with our headers checker for the transport-layer pieces, and you have a delivered audit report in under thirty minutes per site. That's roughly the rate that lets you actually keep up with the plugin churn on a real WordPress estate, which is the only audit cadence that matters.

The rule of WordPress: the install is only as secure as the laziest admin in the last six months, and the laziest admin is usually the one who installed a plugin to do a one-time task and never removed it. The audit catches those. The discipline of running it quarterly is what keeps you out of the news.