DEV Community: Calin V.

Verify Your WordPress Hardening From the Command Line Before You Trust It

Calin V. — Thu, 03 Sep 2026 14:35:46 +0000

Most WordPress hardening advice ends at "turn it on." Almost none of it tells you how to confirm the thing you turned on is doing anything, which is a problem, because the two most common outcomes of configuring a security plugin are a control that silently does nothing and a control that silently breaks your site.

Both look identical from the dashboard. The panel says enabled either way.

What follows is the check I run after configuring hardening on a site, control by control. It is four commands and a rollback drill, and it takes about ten minutes. Everything here runs against a site you own.

Why verification matters more than coverage here

Patchstack's State of WordPress Security in 2026 put 11,334 vulnerabilities across the WordPress ecosystem in 2025, 91% of them in plugins and 9% in themes, with six in core, all low risk. The exposure is the code you installed.

The number that decides your strategy is the next one: 46% of those had no patch available at disclosure, and the weighted median time to first exploitation was five hours. Patching is necessary and it is not, on its own, a plan. So you run a hardening layer underneath it, and the hardening layer is only worth what you can prove it does.

1. Prove the default paths return 404, and that PHP never ran

The first control is reconfiguring the default endpoints so that a scan against wp-login.php, wp-admin, wp-json and the plugin and theme directories fails at reconnaissance.

Checking the status code is the easy half:

SITE="https://example.com"
for p in wp-login.php wp-admin/ wp-json/ wp-content/plugins/ xmlrpc.php; do
  code=$(curl -s -o /dev/null -w '%{http_code}' -L --max-time 10 "$SITE/$p")
  printf '%-26s %s\n' "$p" "$code"
done

A 404 or 403 on the paths you reconfigured is what you want. A 200 on wp-login.php means the setting did not apply, which usually means a caching layer served you a stale page or the rewrite rules were never written.

The harder and more useful half is finding out where that 404 came from. A 404 emitted by the web server from a rewrite rule is a different security property from a 404 emitted by WordPress after it booted, loaded the plugin stack, and decided to deny you. The first one means the exploit path never executed. The second means every line of PHP ran and then politely declined.

Two signals discriminate them. Headers first:

curl -sSI "https://example.com/wp-login.php" | \
  grep -iE 'HTTP/|server|x-powered-by|set-cookie|link|x-redirect-by'

A rewrite-layer rejection is bare: a status line, a server header, a content type, little else. If you see x-powered-by: PHP/8.x, a Set-Cookie carrying a WordPress cookie, or a Link: header advertising the REST API, then WordPress ran. That is the application-layer version of the control.

Then timing, against a known-static file as your baseline:

FMT='%{http_code}  ttfb=%{time_starttransfer}s  total=%{time_total}s\n'
curl -s -o /dev/null -w "$FMT" https://example.com/robots.txt
curl -s -o /dev/null -w "$FMT" https://example.com/wp-login.php
curl -s -o /dev/null -w "$FMT" https://example.com/definitely-not-a-real-path-9f2a

If the blocked path's TTFB sits close to robots.txt, the request died before PHP. If it sits close to a normal WordPress 404, WordPress handled it. Run each three or four times; a single sample on shared hosting tells you nothing.

One caveat worth stating out loud: this is measuring where enforcement happens, not whether an attacker can guess the new path. Those are separate questions and only the first one is testable with curl.

2. Prove the firewall ruleset is actually loaded

A 7G or 8G ruleset rejects injection strings, traversal attempts and malformed requests by pattern. On Apache and LiteSpeed those land as rewrite directives, so they are evaluated before PHP.

Confirm the rules exist on disk first, rather than trusting the panel:

# Apache / LiteSpeed
grep -nE '7G|8G|RewriteCond|RewriteRule' /path/to/site/.htaccess | head -40

# nginx: rules live in the server block, not in .htaccess
sudo nginx -T 2>/dev/null | grep -nE 'location|deny|return 403' | head -40

On nginx this step matters more than people expect. Plenty of plugins write .htaccess unconditionally, and on nginx that file is inert. The panel reports success, the rules are never read, and nothing in the UI says so.

Then send a request that trips a pattern, against your own site:

curl -s -o /dev/null -w '%{http_code}\n' \
  --get --data-urlencode 'p=../../../../etc/passwd' https://example.com/

curl -s -o /dev/null -w '%{http_code}\n' \
  --get --data-urlencode "s=1' UNION SELECT 1,2,3-- -" https://example.com/

403 means the ruleset fired. 200 means the request reached WordPress and was handled as an ordinary query, which is not itself a vulnerability but does tell you the layer you thought was in front is not in front.

Do not over-read a pass here. Patchstack's 2025 pentest of common defences, covering internal host WAFs, Cloudflare, Imunify360 and ModSecurity, found they blocked 12% of attacks against known-exploited vulnerabilities, rising to 26% on a broader test. The best host in the set reached 60.7%. One blocked nothing. A pattern ruleset that answers 403 to a traversal string is working as designed, and working as designed still leaves most real exploit traffic to something else.

3. Prove the login throttle counts, and find the number

Rate limiting is the control most often enabled and least often verified, because verifying it means locking yourself out on purpose. Do that deliberately, on your own site, with a second browser session already open somewhere else.

LOGIN="https://example.com/your-configured-login-path"
for i in $(seq 1 12); do
  code=$(curl -s -o /dev/null -w '%{http_code}' \
    -d "log=verify-throttle-$i&pwd=wrong-on-purpose" \
    -H 'Content-Type: application/x-www-form-urlencoded' \
    --max-time 10 "$LOGIN")
  echo "attempt $i -> $code"
  sleep 1
done

You are looking for the attempt number where the response changes: a 403, a 429, or a body that stops being the login form. That number is your actual lockout threshold, which is frequently not the number in the settings field, because a caching layer or a proxy in front can absorb attempts before they are counted.

While you are here, check what the site does with XML-RPC, which is a second credential endpoint that a login throttle configured only for the form may not cover:

curl -s -X POST https://example.com/xmlrpc.php \
  -H 'Content-Type: text/xml' \
  -d '<methodCall><methodName>system.listMethods</methodName><params></params></methodCall>' \
  | head -c 400

A method list coming back means the endpoint is live. system.multicall is the reason people care: it lets an attacker bundle many credential attempts into a single HTTP request, so a throttle that counts requests rather than attempts undercounts badly.

4. Prove 2FA covers the paths that actually carry credentials

The Verizon 2025 Data Breach Investigations Report found 88% of Basic Web Application attacks involved stolen credentials, which is why a second factor is on the short list at all. Passkeys are the strongest form, because the challenge is bound to your domain and a phished credential cannot be replayed elsewhere.

The gap worth checking is that 2FA usually protects the form, and the form is not the only way credentials enter your site. Application passwords authenticate over REST and are unaffected by two-factor, captcha, throttling, or a reconfigured login path. They are issued once and do not expire on their own.

List what exists:

wp user list --field=ID | while read -r id; do
  echo "== user $id"
  wp user application-password list "$id" --format=table 2>/dev/null
done

Then confirm the credential works without ever touching your login page:

curl -s -u 'username:xxxx xxxx xxxx xxxx xxxx xxxx' \
  https://example.com/wp-json/wp/v2/users/me | head -c 300

If that returns your user object, then every login control you configured is out of the request path for that credential, by construction. Which is fine when you provisioned it deliberately and know it exists. It is a problem when it was issued for a mobile app in 2023 by somebody who has left.

Revoke what you cannot account for:

wp user application-password delete <user-id> <uuid>

5. Rehearse the rollback before you need it

This is the step that decides whether any of the above survives, and it is the one nobody does.

Find your recovery path while you can still log in, then actually run it once:

# WP-CLI, if you have shell access
wp plugin deactivate <plugin-slug>
wp rewrite flush --hard

# no shell: rename the plugin directory over SFTP
mv wp-content/plugins/<plugin-slug> wp-content/plugins/<plugin-slug>.off

# and keep a known-good copy of the rewrite rules before you change anything
cp .htaccess .htaccess.pre-hardening

Two things to confirm during the drill. First, that deactivating restores the default paths immediately rather than leaving a half-applied rewrite state, which is the difference between a plugin that writes rules and one that also modifies core files. Second, that you know your vendor's documented bypass URL, if it has one, and that it is bookmarked somewhere you can reach from a phone.

A control you cannot reverse under pressure is a control you will eventually disable permanently at 2am, and a permanently disabled control protects nothing.

The short version

Four commands and a drill:

curl -I the default paths, and use TTFB against a static file to tell a rewrite-layer 404 from a PHP one.
grep the actual server config for the ruleset, then trip one pattern and expect 403. On nginx, check that .htaccess is not being written into the void.
Loop failed logins until the status code changes, and find out whether the real threshold matches the configured one. Check xmlrpc.php separately.
List application passwords, prove one authenticates without the login form, and revoke what you cannot account for. Then rehearse the rollback while you are still logged in.

What is the check you run that is not on this list? I am specifically after the one that caught something the dashboard reported as fine.

Measure What a Security Plugin Costs You, Instead of Reading the Benchmark

Calin V. — Sat, 29 Aug 2026 07:58:19 +0000

Every security plugin vendor publishes a performance claim, and none of them are measuring your site. The host, the PHP version, the opcode cache, the traffic mix and whatever else is installed all move the result more than the plugin does. I am not going to give you a percentage in this post, because I do not have one I would defend in a code review.

What I can give you is the method. Half an hour of setup produces numbers about your stack, and those numbers settle the argument that vendor benchmarks never will.

Three things are worth measuring separately, because they behave differently and get confused constantly:

Per-request cost. PHP executed on every hit, whether or not anything security-relevant happened.
Write cost. Rows inserted per event the plugin decides to record. Scales with traffic, not with legitimate traffic.
Storage cost. What the accumulated records weigh, and specifically how much of it WordPress loads into memory on every single request. The third one is where the hundred-megabyte options-table stories come from, and it is almost always a logging feature rather than a firewall.

Per-request cost: median TTFB, not one curl

A single curl -w is noise. Take the median of a run and compare medians.

#!/usr/bin/env bash
# ttfb.sh - median time-to-first-byte over N requests
# usage: ./ttfb.sh https://staging.example.com/ 40
set -euo pipefail

URL="${1:?usage: ttfb.sh <url> [n]}"
N="${2:-40}"
TMP=$(mktemp)

for _ in $(seq "$N"); do
  curl -sS -o /dev/null \
       -H 'Cache-Control: no-cache' \
       -w '%{time_starttransfer}\n' \
       --max-time 20 "$URL" >> "$TMP"
  sleep 0.4
done

sort -g "$TMP" | awk -v n="$N" '
  { v[NR] = $1 }
  END {
    printf "n=%d  min=%.3f  p50=%.3f  p90=%.3f  max=%.3f\n",
      NR, v[1], v[int(NR*0.5)+0], v[int(NR*0.9)+0], v[NR]
  }'
rm -f "$TMP"

Rules that make the output mean something:

Run it against staging, not production, and against a URL your page cache does not serve. A cached response measures your cache, not your plugin stack.
Send Cache-Control: no-cache and pick a path with a query string if your cache is aggressive.
Compare p50 and p90 from the same machine, at the same time of day, on the same host. Cross-host comparisons are worthless. Now the A/B. Deactivate one plugin, re-measure, reactivate:

#!/usr/bin/env bash
# ab-plugin.sh - measure with a plugin off, then back on
set -euo pipefail
URL="$1"; SLUG="$2"

echo "== baseline (all active)"; ./ttfb.sh "$URL" 40
wp plugin deactivate "$SLUG" >/dev/null
echo "== without $SLUG";        ./ttfb.sh "$URL" 40
wp plugin activate "$SLUG" >/dev/null
echo "== restored";             ./ttfb.sh "$URL" 40

The third run matters. If "restored" does not land near "baseline", something else moved during the test and the middle number is not trustworthy.

For attribution inside a single page load rather than a difference between two, Query Monitor breaks queries and hook time down per plugin on a live request, and the WP-CLI profile package does it from the shell:

wp package install wp-cli/profile-command:@stable
wp profile stage --allow-root
wp profile hook --all --spotlight --orderby=time --order=desc | head -20

Storage cost: aggregate autoload weight by plugin, not by option

Total autoloaded weight first. This is what gets pulled into memory on every request, including requests that have nothing to do with security:

SELECT SUM(LENGTH(option_value)) AS autoload_bytes,
       COUNT(*)                  AS autoload_rows
FROM wp_options
WHERE autoload IN ('yes','on','auto','auto-on');

The accepted values in the autoload column were expanded in recent WordPress releases, so the IN list keeps this working across versions. Anything past a few hundred kilobytes is worth chasing.

Listing the top twenty options is the usual next step, and it is fine, but it buries a plugin that autoloads two hundred small options under one plugin that autoloads a single large one. Aggregate by prefix instead:

SELECT
  SUBSTRING_INDEX(TRIM(LEADING '_' FROM option_name), '_', 1) AS prefix,
  COUNT(*)                                                    AS rows_n,
  ROUND(SUM(LENGTH(option_value)) / 1024, 1)                  AS kb
FROM wp_options
WHERE autoload IN ('yes','on','auto','auto-on')
GROUP BY prefix
HAVING kb > 5
ORDER BY kb DESC
LIMIT 25;

Option names carry the prefix of the plugin that created them, so this names the responsible plugin directly and ranks by what it actually costs rather than by the size of its largest single row. Core's own prefixes show up too, which is a useful sanity check on the query.

Through WP-CLI, if you would rather not open a SQL client:

wp option list --autoload=on --fields=option_name,size_bytes \
  --format=csv \
| awk -F, 'NR>1 { split($1, p, "_"); k = p[1] ? p[1] : p[2]; s[k] += $2 }
           END { for (i in s) printf "%10.1f KB  %s\n", s[i]/1024, i }' \
| sort -rn | head -20

And table sizes, where accumulated logs live rather than autoloaded settings:

SELECT table_name,
       table_rows,
       ROUND((data_length + index_length) / 1024 / 1024, 2) AS mb
FROM information_schema.TABLES
WHERE table_schema = DATABASE()
ORDER BY (data_length + index_length) DESC
LIMIT 15;

Two things to rule out before blaming security tooling. Transients that never expired are a common cause of options growth and usually come from caching or import plugins. And orphaned tables from plugins deleted years ago keep every row, because uninstalling removes the code and not the data.

Write cost: measure the growth rate, not the size

A table's current size tells you where you are. Its growth rate tells you where you will be in six months, and that is the number that decides whether a logging feature is sustainable on this site.

Sample it on a schedule:

#!/usr/bin/env bash
# table-growth.sh - append a size sample; run hourly from cron
set -euo pipefail
LOG=/var/log/wp-table-sizes.csv
[ -f "$LOG" ] || echo "ts,table,mb,rows" > "$LOG"

wp db query "
  SELECT table_name, ROUND((data_length+index_length)/1024/1024,3), table_rows
  FROM information_schema.TABLES
  WHERE table_schema = DATABASE()
  ORDER BY (data_length+index_length) DESC LIMIT 15;" --skip-column-names \
| awk -v ts="$(date +%FT%T)" 'BEGIN{OFS=","} {print ts, $1, $2, $3}' >> "$LOG"

# crontab -e
17 * * * * /usr/local/bin/table-growth.sh

After a couple of days, bytes per day per table:

awk -F, 'NR>1 { if (!(($2) in first)) { first[$2]=$3; ft[$2]=$1 } last[$2]=$3; lt[$2]=$1 }
         END { for (t in last)
                 printf "%-40s %8.2f MB now  %+7.2f MB since %s\n",
                        t, last[t], last[t]-first[t], ft[t] }' \
  /var/log/wp-table-sizes.csv | sort -k2 -rn

Run it across a weekday and a weekend. Log tables that grow with bot traffic have a very different curve from tables that grow with human activity, and knowing which one you have tells you whether a retention setting fixes it or whether you need the traffic to stop arriving.

Before you delete anything: most logging features ship a retention or pruning setting that defaults to keeping everything, and that is the first place to look. Deleting options a plugin actively reads will break it, and some log tables are referenced by the plugin's own admin screens. Back up first.

What the numbers will not tell you

Two limits worth stating, because a set of scripts like this invites over-reading.

A low blocked-attack count on a dashboard is ambiguous. An operator running fail2ban across two servers posted his jail counts on r/Wordpress this month: crawlers banned 915 and 1,129, the wp-login jails 15,189 and 50,386, the xmlrpc jails 11,345 and 9,530. Those are his counters on his servers, not a general measurement. His conclusion is the useful part and it generalises fine: those bans happen at the server before PHP starts, so no plugin sees that traffic and none of it appears in any dashboard. A low count can mean less attack traffic, or it can mean something upstream absorbed it. From inside WordPress those look identical.

Cheap layers cannot see everything. A rule evaluated before PHP starts can only answer questions that can be settled from the request itself. It does not know who is logged in or whether a user has the capability they are claiming. Broken access control was the largest single category Patchstack's RapidMitigate blocked in 2025, at 57% of attacks, precisely because it resembles normal authenticated traffic. Nothing at the rewrite layer catches that, and moving enforcement earlier trades visibility and context for cost.

So this answers "what does this cost me", which is a real question with a measurable answer. It does not answer "is this the right control", which depends on what you are defending against.

One question

If you have chased an options table into the hundreds of megabytes: what was actually at the top of the list when you aggregated by prefix? Mine has been a caching plugin more often than a security plugin, and I would like to know whether that holds for anyone else.

I run engineering at Squirrly and spend more time in access logs than I would choose to. The article this accompanies, with the layer comparison in full, is here: https://wpghost.com/lightweight-wordpress-security-plugin/

Start with an inventory you can diff against next year

Calin V. — Sat, 29 Aug 2026 07:01:29 +0000

WP-CLI already knows most of what you need.

wp plugin list \
  --fields=name,title,status,version,update,update_version,auto_update \
  --format=csv > "inventory-$(date +%F).csv"

Run that on every site and keep the files. A year of these is a version history you did not have to ask a vendor for, and the diff between two of them answers the renewal question directly.

For a portfolio, fan it out over an alias group and tag each row with the site:

#!/usr/bin/env bash
# inventory.sh - collect plugin state across an alias group into one CSV
set -euo pipefail

OUT="inventory-$(date +%F).csv"
echo "site,name,version,update,update_version,status" > "$OUT"

for site in $(wp @all cli info --format=json 2>/dev/null | jq -r 'keys[]'); do
  wp "@$site" plugin list \
     --fields=name,version,update,update_version,status \
     --format=csv --skip-plugins --skip-themes 2>/dev/null \
   | tail -n +2 \
   | sed "s/^/$site,/" >> "$OUT"
done

wc -l "$OUT"

--skip-plugins --skip-themes keeps a broken plugin from taking the inventory run down with it. You want the census even when one site is unhappy.

Ask the directory what changed, for the plugins it knows about

For anything hosted on wordpress.org, the public API will tell you the release history without any authentication.

slug="query-monitor"

curl -sS "https://api.wordpress.org/plugins/info/1.0/${slug}.json" \
  | jq '{
      name,
      version,
      last_updated,
      active_installs,
      tested,
      requires_php,
      releases: (.versions | keys | map(select(. != "trunk")) | sort | .[-8:])
    }'

Two fields matter for a renewal decision. last_updated tells you whether the product is being worked on at all. The tail of versions tells you how many releases shipped in the period you paid for, which is a proxy for whether the value arrived as a stream or as a one-time setup.

A wrapper over the whole inventory, so you get one table instead of forty curl calls:

#!/usr/bin/env bash
# release-cadence.sh - how many releases has each .org plugin shipped, and when was the last one
set -euo pipefail

printf '%-32s %-12s %-22s %s\n' SLUG INSTALLED LAST_UPDATED RELEASES_KNOWN

wp plugin list --field=name --status=active | while read -r slug; do
  json=$(curl -sS --max-time 10 \
    "https://api.wordpress.org/plugins/info/1.0/${slug}.json" 2>/dev/null || echo '{}')

  # a premium plugin is not in the directory and returns null or an error object
  if [ "$(echo "$json" | jq -r 'type')" != "object" ] || [ "$(echo "$json" | jq -r '.version // "null"')" = "null" ]; then
    printf '%-32s %-12s %-22s %s\n' "$slug" "$(wp plugin get "$slug" --field=version)" "not-in-directory" "-"
    continue
  fi

  printf '%-32s %-12s %-22s %s\n' \
    "$slug" \
    "$(wp plugin get "$slug" --field=version)" \
    "$(echo "$json" | jq -r '.last_updated' | cut -d' ' -f1)" \
    "$(echo "$json" | jq -r '.versions | keys | length')"
done

The rows that print not-in-directory are the interesting ones. Those are your paid plugins, and they are exactly the ones the public tooling cannot help you with.

The integrity check does not cover the things you pay for

This is the part that surprised me when I first hit it, and it is load-bearing for anyone reasoning about premium plugin risk.

wp plugin verify-checksums --all

That command compares the files on disk against the checksums published by wordpress.org. It works, it is fast, and it is genuinely useful for catching tampering. It also only works for plugins hosted in the directory. A premium plugin returns something like:

Warning: Could not retrieve the checksums for version 4.1.2 of plugin acme-pro, skipping.

There is no published source of truth to compare against, because the vendor distributes the zip themselves. It is documented behaviour on developer.wordpress.org and a long-standing open request in the wp-cli repo, not a bug in your setup.

The implication is worth stating plainly. The one built-in integrity check WordPress ships does not cover premium plugins, which is precisely where vendor-delivered tampering has actually occurred. The ShapedPlugin compromise in June 2026, CVE-2026-10735 at CVSS 9.8, distributed backdoored builds to paying customers through the vendor's own update system. As reported by BleepingComputer and The Hacker News, and per data collected by Defiant, the backdoor went into the Pro builds on 21 May and the first customer reports arrived on 10 June, so roughly twenty days passed with the malicious release being served as a legitimate update. Only the paid tiers were affected.

wp core verify-checksums is the equivalent for core and does work, so run it anyway:

wp core verify-checksums

Diff what a release actually changed

For premium plugins, the only reliable record of what you bought is the code itself. Keep the plugin directory in git and every update becomes a reviewable diff.

cd wp-content/plugins
git init
printf '*/cache/\n*/logs/\n*.log\n' > .gitignore
git add -A
git commit -m "baseline $(date +%F)"

Then commit after each update round, on a schedule, with the version in the message:

#!/usr/bin/env bash
# snapshot.sh - commit the plugin tree after an update round
set -euo pipefail
cd "$(wp plugin path)"

wp plugin list --fields=name,version --format=csv > .versions.csv
git add -A
git commit -q -m "plugins $(date +%F)" || { echo "no change"; exit 0; }
git --no-pager log -1 --stat | head -40

A year later, the renewal question has an exact answer:

# what did this vendor ship in the last 12 months, by volume and by file
git log --since='12 months ago' --oneline -- acme-pro | wc -l
git diff --stat "@{12 months ago}" HEAD -- acme-pro

Read the diff, not just the counter. A vendor shipping eleven releases that only bump a version constant and update a readme is not the same as a vendor shipping four releases that rewrite the request handling. I have had both, and only one of them was worth the renewal.

Two things to keep in mind before you do this on a real server. The tree contains no secrets in a normal install, but check for any plugin writing licence keys into its own directory before you commit, and never push the repo anywhere public. And keep the repo out of the web root's reachable space, or at minimum confirm your server config rejects requests for .git.

Put a number on it

Once you have release cadence and diff volume, the pricing comparison stops being a feeling. This computes break-even against a one-time price and prints the cadence you measured alongside it, so you are not deciding on cost alone.

#!/usr/bin/env python3
"""breakeven.py - compare annual vs one-time licensing across an inventory.

Usage: ./breakeven.py licences.csv
CSV columns: name,annual,onetime,kind,releases_12mo
  kind = detection | configuration
"""
import csv
import sys

HORIZON = 6  # years to model

def main(path):
    rows = list(csv.DictReader(open(path)))
    print(f"{'plugin':<24}{'kind':<15}{'rel/yr':>7}{'annual':>9}{'once':>8}{'break-even':>12}")
    total_annual = 0.0
    for r in rows:
        annual = float(r["annual"] or 0)
        once = float(r["onetime"] or 0)
        total_annual += annual
        if annual <= 0 or once <= 0:
            be = "n/a"
        else:
            years = once / annual
            be = f"{years:.1f} yr" if years <= HORIZON else f">{HORIZON} yr"
        print(f"{r['name']:<24}{r['kind']:<15}{r['releases_12mo']:>7}{annual:>9.0f}{once:>8.0f}{be:>12}")

    print(f"\nannual spend: {total_annual:.0f}/yr, {total_annual * HORIZON:.0f} over {HORIZON} years")

    stale = [r for r in rows
             if r["kind"] == "configuration" and int(r["releases_12mo"] or 0) <= 2]
    if stale:
        print("\nconfiguration tooling with <=2 releases in 12 months (review these first):")
        for r in stale:
            print(f"  - {r['name']}: {r['releases_12mo']} releases, {float(r['annual']):.0f}/yr")

if __name__ == "__main__":
    main(sys.argv[1] if len(sys.argv) > 1 else "licences.csv")

The kind column is doing the real work, and it is the one judgement call in the whole exercise. Detection products are worth the most on the day after a new vulnerability lands, so their value arrives as a stream and a recurring fee matches it. Configuration products apply a setting once and then hold it, so the maintenance curve is flatter. A plugin in the second category shipping two releases a year is the row where recurring pricing is doing the least work for you.

Why any of this matters more than a tighter budget

Two findings from Patchstack's State of WordPress Security in 2026 changed how I read a renewal invoice.

The first: of 1,983 valid vulnerability reports filed against premium or freemium WordPress products in 2025, 76% were rated exploitable in real-world attacks, and premium products carried three times as many Known Exploited Vulnerabilities as free ones. Paying buys you features, support and a vendor with a commercial reason to respond. It does not buy you a product with fewer flaws, and reading it as a quality signal is a mistake.

The second: 46% of 2025 vulnerabilities had no patch available at disclosure, and the weighted median time to first exploitation was five hours. The report's own line on the first figure is that it shows why site owners cannot rely on plugin updates as a security measure. For roughly half of last year's disclosures, updating within a day was not slow, it was impossible.

Both of those push the same way. What you can measure, budget and verify is your own configuration and your own inventory. What you cannot control is when the next disclosure lands or whether a fix exists when it does.

What this does not tell you

Release cadence is a proxy, not a verdict. A mature product with a small surface can legitimately ship twice a year, and diff volume rewards churn. Read the diffs before cancelling anything.

It also says nothing about support quality, which for some teams is the entire product, and nothing about whether the plugin is doing its job. This is a purchasing audit, not a security audit.

One question

For anyone running more than ten client sites: what do you check before renewing a plugin licence, other than whether it is still installed? I have asked a lot of agencies this and the honest answer is usually nothing.

I run engineering at Squirrly and spend more time in access logs than I would choose to. The longer argument about which licensing model fits which kind of tool is here: https://wpghost.com/lifetime/

The integrity check you already have skips your paid extensions

Calin V. — Sat, 22 Aug 2026 10:06:29 +0000

WP-CLI ships a real integrity check. It compares installed plugin files against the checksums published by wordpress.org:

wp plugin verify-checksums --all

On a blog, that is a decent baseline. On a store, run it and read the warnings rather than the success line:

Warning: Could not retrieve the checksums for version 5.4.1 of plugin woocommerce-subscriptions, skipping.
Warning: Could not retrieve the checksums for version 1.15.6 of plugin woocommerce-bookings, skipping.
Warning: Could not retrieve the checksums for version 3.2.0 of plugin advanced-shipping-rates, skipping.
Success: Verified 12 of 34 plugins.

The skips are not a bug. Checksums exist only for plugins hosted in the wordpress.org directory. Premium and custom plugins have no published source of truth to compare against, which is documented behaviour and a long-standing open request in the wp-cli repo. wp core verify-checksums works fine for core, because core publishes checksums.

Now line that up with what a WooCommerce build is. Gateways, subscriptions, shipping logic, tax, currency, abandoned-cart recovery. Fifteen to forty extensions attached to the payment path, and nearly all of them paid. According to Patchstack's State of WordPress Security in 2026, 91% of the 11,334 vulnerabilities disclosed across the ecosystem in 2025 were in plugins rather than core, and of 1,983 valid reports against premium or freemium products, 76% were rated exploitable in real-world attacks, with premium products carrying three times as many known exploited vulnerabilities as free ones.

The one integrity check WordPress gives you covers the third of your plugin list with the least exposure, and skips the two thirds with the most.

Build the baseline the checksum command cannot

If nobody publishes a manifest for your paid extensions, publish your own. Do it immediately after an update, from a state you have reason to trust, and store it off the box.

#!/usr/bin/env bash
# baseline.sh - snapshot every plugin file hash after a known-good update
set -euo pipefail

WP_ROOT="/var/www/store"
OUT="/opt/manifests/plugins-$(date +%Y%m%d-%H%M).sha256"

find "${WP_ROOT}/wp-content/plugins" \
  -type f \( -name '*.php' -o -name '*.js' \) \
  -not -path '*/node_modules/*' \
  -print0 | sort -z | xargs -0 sha256sum > "${OUT}"

ln -sfn "${OUT}" /opt/manifests/plugins-latest.sha256
echo "wrote ${OUT} ($(wc -l < "${OUT}") files)"

Then the check, which is the half that runs on a schedule:

#!/usr/bin/env bash
# drift.sh - fail loudly if a plugin file changed outside an update window
set -uo pipefail

if ! sha256sum -c --quiet /opt/manifests/plugins-latest.sha256 2>/dev/null; then
  echo "PLUGIN FILE DRIFT on $(hostname) at $(date -Is)" >&2
  exit 1
fi
echo "clean"

Two things make this worth the twenty minutes. It covers premium code, which is the part verify-checksums cannot see. And it produces a dated artifact, which matters later, because "when did this file change" is the first question anyone asks and the hardest one to answer after the fact.

One honest limit up front. File hashing catches changes on disk. It does not catch a compromise where no plugin file changes at all, which is a real shape: a plugin that renders a remote feed inside wp-admin can serve attacker-controlled content while every file on the server hashes clean. Treat drift detection as one signal, not the answer.

Watch what the checkout page actually loads

A skimmer earns in the browser, so check the browser. The useful inventory is not "what plugins are installed" but "what script origins does my checkout page pull from, and has that set changed".

Collect the current set from the rendered page:

// paste in DevTools on /checkout/, in an incognito window, logged out
[...document.querySelectorAll('script[src]')]
  .map(s => new URL(s.src, location.href).origin)
  .filter((v, i, a) => a.indexOf(v) === i)
  .sort();

On a working store that list is short and boring. Your own origin, the payment gateway, maybe an analytics host. If a fourth origin you do not recognise is in there, you have found something without running a scanner.

Once you know the real set, enforce it. Content-Security-Policy on the checkout route turns the inventory into a control, because a script injected from anywhere else stops executing:

location = /checkout/ {
    add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://js.stripe.com; frame-src https://js.stripe.com; connect-src 'self' https://api.stripe.com; object-src 'none'; base-uri 'self'" always;
}

Ship it in Content-Security-Policy-Report-Only with a report-uri for a week first. A checkout is the worst page on the site to break silently, and page builders and tag managers will surface violations you did not predict.

Change what a scanner can map before it maps it

The reconnaissance step is cheap for the attacker and it is the step you can actually take away. An automated crawler reads paths and version strings, matches them against a public vulnerability list, and only then decides your store is worth a request. Break that chain and a large share of traffic never reaches the exploit stage, because the target selection fails.

Stop advertising versions:

// mu-plugin: 000-no-fingerprints.php
add_filter('the_generator', '__return_empty_string');
remove_action('wp_head', 'wp_generator');
remove_action('wp_head', 'rsd_link');
remove_action('wp_head', 'wlwmanifest_link');

// drop the ?ver= query string that pins every asset to a release
add_filter('style_loader_src', 'store_strip_ver', 10, 1);
add_filter('script_loader_src', 'store_strip_ver', 10, 1);
function store_strip_ver($src) {
    return $src ? remove_query_arg('ver', $src) : $src;
}

Return 404 on the endpoints a store has no reason to expose publicly, at the rewrite layer, before PHP starts:

# probes that only ever precede an exploit attempt on a store
location ~* ^/(wp-config\.php\.(bak|old|save|swp)|\.env|\.git/) { return 404; }
location = /xmlrpc.php { return 404; }
location ~* ^/wp-content/(plugins|themes)/[^/]+/readme\.txt$ { return 404; }
location ~* ^/wp-content/uploads/.*\.(php|phtml|phar)$ { return 404; }

Apache, same idea:

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteRule ^wp-content/(plugins|themes)/[^/]+/readme\.txt$ - [R=404,L]
  RewriteRule ^wp-content/uploads/.*\.(php|phtml|phar)$ - [R=404,L]
  RewriteRule ^xmlrpc\.php$ - [R=404,L]
</IfModule>

Those readme.txt files are the quiet one. Every plugin ships one, it names the plugin and its version in plain text, and a crawler reads it without authenticating. Reconfigure the response and version-matched targeting fails at the reconnaissance step.

Two numbers that explain why this sits alongside patching rather than after it. Patchstack 2026 puts the weighted median time to first exploitation at five hours, and reports that 46% of 2025 vulnerabilities had no patch available at disclosure. Patch on the day, which is faster than most portfolios manage, and you are still late for a large share of disclosures, with nothing to apply for roughly half of them.

What this stack does not do

It does not detect and it does not clean. Everything above reduces what is reachable and tells you when something on disk moved. None of it finds malware already resident, and rewrite rules have nothing to say about a file that is already executing.

If you think a skimmer is live in your checkout right now, the order is the other way round. Scan and clean with something built for detection, restore from a backup you have reason to trust, then close the path. Doing surface reduction first feels productive and accomplishes very little.

Worth knowing before the cleanup, because it changes what "done" means: Patchstack 2026 records that the two top variants of the Monarx/Lock360 malware family accounted for 38% and 32% of all injected file detections in 2025, and that the family rewrites cleaned files from server memory as they are restored. Monarx's own conclusion, from roughly nine trillion file signals, is that signature-based delete-only security is no longer sufficient. A clean that leaves the entry path open frequently does not hold.

And the part that is not a technical decision. If card data was skimmed, this is a cardholder-data event under PCI DSS rather than a cleanup job, and the disclosure obligations depend on how your gateway handles card data. That is worth establishing while nothing is wrong, not during.

One question

For the people running stores in production: what is actually watching your paid extensions between updates? A hash manifest, a commercial file-integrity service, your host, or, if we are being honest about it, nothing at all?

I run engineering at Squirrly and spend more time in access logs than I would choose to. The longer version of this argument, with the layer comparison as a table, is here: https://wpghost.com/woocommerce-security/

The pre-flight checklist for a WordPress passwordless rollout (so you don't lock yourself out)

Calin V. — Fri, 07 Aug 2026 15:14:40 +0000

You are about to turn on passwordless login for a WordPress site that other people use. The security case is well covered elsewhere. This post is the part that goes wrong: the endpoint you just exposed, the recovery path you have not decided yet, and the fifteen minutes of testing that separates a rollout from an incident.

Order of operations first, because it is most of the value here:

Enable the factor on one test account. Nobody else.
Enrol administrators.
Decide and document the recovery path.
Widen to everyone, with the old factor still working in parallel. Turning a second factor on for every user at once, on a site where some fraction of members have a dead address on file, converts a support queue into a support incident. Everything below is the detail inside those four steps.

1. Verify the origin binding actually works before you trust it

The reason a passkey resists phishing is a string comparison the browser performs, not a policy you configure. When a credential is created, it is bound to the relying party ID, which is your registered domain. At authentication the browser compares the origin of the page requesting a signature against that RP ID and refuses to surface the credential on a mismatch.

You can watch this in the console rather than taking it on faith. On your real login page:

navigator.credentials.get({
  publicKey: {
    challenge: Uint8Array.from(crypto.getRandomValues(new Uint8Array(32))),
    rpId: location.hostname,
    userVerification: "preferred",
    timeout: 60000
  }
}).then(c => console.log("credential offered:", c))
 .catch(e => console.log("refused:", e.name, e.message));

Run the same snippet from a copy of the page served on any other hostname you control. The rpId will not match the enrolled origin and the call fails before the user is prompted. That is the whole anti-phishing mechanism, and it is worth confirming once on your own stack.

Two things to check while you are here:

The site must be HTTPS. WebAuthn is available only in a secure context. localhost is exempt for development.
Decide the RP ID deliberately if you use subdomains. A credential registered with rpId: "example.com" is usable on shop.example.com. One registered with rpId: "shop.example.com" is not usable on the apex. Getting this wrong on a multisite or a subdomain store is the most common enrolment bug I have seen. Worth knowing what this control is worth: the Verizon 2025 Data Breach Investigations Report puts stolen credentials in 88% of Basic Web Application attacks, and credential stuffing at a median 19% of daily authentication attempts on affected applications. The origin check is aimed squarely at that traffic.

2. You just added an unauthenticated endpoint. Rate limit it

Magic link login means a route that accepts an email address from anyone and sends mail. That is a new unauthenticated write surface on your site, and it needs the same treatment as /wp-login.php.

nginx, limiting token requests to 1 per 20 seconds per IP with a small burst:

limit_req_zone $binary_remote_addr zone=magiclink:10m rate=3r/m;

location = /wp-json/your-namespace/v1/magic-link {
    limit_req zone=magiclink burst=2 nodelay;
    limit_req_status 429;
    try_files $uri $uri/ /index.php?$args;
}

Apache 2.4 with mod_ratelimit is weaker for this; if you are on Apache, do it in PHP or at the edge. A minimal in-application throttle keyed on the submitted address rather than only the IP:

add_action( 'init', function () {
    if ( ! isset( $_POST['magic_link_email'] ) ) {
        return;
    }
    $email = sanitize_email( wp_unslash( $_POST['magic_link_email'] ) );
    $key   = 'ml_throttle_' . md5( $email . '|' . $_SERVER['REMOTE_ADDR'] );

    if ( get_transient( $key ) ) {
        status_header( 429 );
        wp_die( 'Too many requests. Try again in a minute.', 429 );
    }
    set_transient( $key, 1, 60 );
} );

Key on both the address and the IP. IP alone is trivially rotated; address alone lets one attacker lock a specific user out of their own login.

Token rules worth enforcing regardless of implementation: single use, short lifetime (10 to 15 minutes is the usual compromise), invalidated on use and on a new issue, and never logged. A magic link is a bearer token. Whoever holds the URL is authenticated, which also means it should not end up in a Referer header or an analytics query string.

3. Decide the recovery path before it is an incident

Remove passwords and your account recovery flow becomes the weakest link in the chain. This is not a criticism of passkeys, it is arithmetic: the attacker moves to the cheapest remaining path.

Pick one and write it into your runbook:

Recovery path	Cost	Failure mode
Second enrolled device	Zero, if enforced at enrolment	Users skip it unless the UI blocks them
Hardware key in a drawer	One key per admin	Only works if someone can physically reach it
Admin-initiated re-enrolment	Support time	Only as strong as your identity check on the requester
Emailed recovery link	Free	Collapses account security into mailbox security

If your recovery is an unverified email request, you have relocated the vulnerability rather than removed it.

The one that catches teams out is the second row. A hardware key stored in an office nobody visits is not a recovery path, it is a story about one.

4. Get-back-in procedures, tested on staging first

Test these before you need them, on a copy, with the site's real plugin set active.

Deactivate the security plugin over SSH or WP-CLI, which restores the default login without touching core:

wp plugin deactivate your-security-plugin --path=/var/www/example.com

No WP-CLI, no shell, only SFTP? Rename the plugin directory. WordPress deactivates a plugin whose folder has disappeared:

mv wp-content/plugins/your-security-plugin wp-content/plugins/your-security-plugin.off

Confirm you can create an emergency administrator from the CLI, and delete it the moment you are done:

wp user create breakglass ops@example.com --role=administrator --user_pass="$(openssl rand -base64 24)"
# ... regain access, fix the enrolment, then:
wp user delete breakglass --reassign=1

Run all three on staging. A recovery procedure you have never executed is a hypothesis.

5. The end-to-end test that catches the real breakages

Second-factor prompts attach to the login form. They do not attach to checkout or to the block editor, so a normal customer purchase is unaffected. The failure mode is a custom or plugin-rendered login form that bypasses the standard hooks and therefore never shows the prompt.

Check the response and the redirect chain directly rather than eyeballing the page:

# Does the login form still return 200 and set the expected test cookie?
curl -sS -o /dev/null -w '%{http_code} %{redirect_url}\n' \
  https://example.com/wp-login.php

# Is the token endpoint actually throttling?
for i in $(seq 1 6); do
  curl -sS -o /dev/null -w '%{http_code}\n' \
    -X POST -d 'magic_link_email=test@example.com' \
    https://example.com/wp-json/your-namespace/v1/magic-link
done

That loop should return a 429 before it finishes. If it returns six 200s, your throttle is not wired up.

Then walk one real account through, in this order: WooCommerce account login, any custom front-end login form, password reset, the second-factor prompt itself, and recovery. Five clicks, one account, before anyone else is enrolled.

What this does not cover, and why that matters operationally

Everything above hardens the credential path. It is the highest-value change most WordPress sites can make to their login layer, and it is also the entire scope of what it does.

Three classes of attack are untouched by all of it, because the attacker never reaches the form:

Pre-authentication plugin vulnerabilities. Exploited by an unauthenticated request. There is no login event in that path to strengthen. Patchstack's State of WordPress Security in 2026 reports 11,334 new WordPress-ecosystem vulnerabilities disclosed in 2025, a 42% year-on-year rise, with 91% of them in plugins rather than core.
A compromised plugin update channel. WordPress fetches, unpacks and executes vendor code on a schedule, with no authentication event anywhere in it.
Client-side skimmers on checkout. The attacker reads what the customer types. Your admin login was never involved. The same Patchstack report records 20% of heavily-exploited vulnerabilities under active attack within six hours of disclosure, 45% within twenty-four hours, and 70% within seven days. Against a six-hour window, the control that matters is reducing what is reachable and patching fast, not strengthening a form the attacker skipped. Two surfaces, two controls, and the mistake is finishing one and believing you finished both.

Before you enrol anyone, run the throttle loop in section 5 against your own token endpoint. I would like to know how many people get six 200s back, because that endpoint tends to ship without a limiter and nobody notices until the mail queue does.

Audit your robots.txt AI block list: a script that checks what your rules actually do

Calin V. — Tue, 04 Aug 2026 10:33:39 +0000

Your robots.txt has an AI block in it. You pasted it at some point, it looked right, and you have not read it since. This post is a script that tells you what it is actually enforcing, because in my experience the answer is usually "not what you think" in one of four specific ways.

The short version of the problem: every major vendor now runs three bots, not one.

Vendor	Training	Search / retrieval	User-triggered fetch
Anthropic	`ClaudeBot`	`Claude-SearchBot`	`Claude-User`
OpenAI	`GPTBot`	`OAI-SearchBot`	`ChatGPT-User`
Perplexity	`PerplexityBot`	(same bot indexes)	`Perplexity-User`
Google	`Google-Extended`	`Googlebot`	n/a

Blocking the training bot costs you nothing. Blocking the search bot removes you from that vendor's answers. Most pasted block lists hit both, because they match on a vendor prefix instead of on individual tokens.

And the promises differ per vendor, which is the part that decides your implementation:

Anthropic states all three of its crawlers honour robots.txt, including the user-triggered Claude-User.
OpenAI documents that robots.txt rules may not apply to ChatGPT-User. So a robots.txt entry is a credible control across Anthropic's whole family, and is not sufficient for OpenAI's fetcher. Same three-tier shape, different enforceable surface.

1. Dump what you are actually serving

Not the file on disk. What the origin returns. On WordPress these differ constantly: with no physical robots.txt, core generates a virtual one, so editing the file you think exists is a silent no-op.

BASE="https://example.com"

# what the world sees
curl -s "$BASE/robots.txt" | grep -iE 'user-agent|disallow' | sed 's/^/  /'

# is it physical or virtual? a physical file usually carries an ETag / Last-Modified
curl -sI "$BASE/robots.txt" | grep -iE 'etag|last-modified|x-cache|cf-cache-status'

If your edits are not in that first output, stop here. Nothing else you configured is running either.

2. Flag deprecated tokens

Anthropic retired Claude-Web and anthropic-ai. They are harmless to keep, but their presence dates the file: a rule set naming them was written in 2024 and has not been reread since, which means every other decision in it is also a 2024 answer.

curl -s "$BASE/robots.txt" \
  | grep -iE 'claude-web|anthropic-ai|cohere-ai|omgili' \
  && echo "^^ deprecated tokens present - this file needs a full reread"

3. Test enforcement per bot, in both directions

This is the part that matters, and the assertion nobody writes is the second one: the search bot must still get a 200.

#!/usr/bin/env bash
# ai-crawler-audit.sh - verify per-bot policy against a live origin
BASE="${1:?usage: ai-crawler-audit.sh https://example.com}"

# agent | expected: BLOCK or ALLOW
BOTS=(
  "ClaudeBot|BLOCK"
  "Claude-SearchBot|ALLOW"
  "Claude-User|ALLOW"
  "GPTBot|BLOCK"
  "OAI-SearchBot|ALLOW"
  "ChatGPT-User|ALLOW"
  "PerplexityBot|BLOCK"
  "Google-Extended|BLOCK"
  "Googlebot|ALLOW"
)

fail=0
for entry in "${BOTS[@]}"; do
  ua="${entry%%|*}"; want="${entry##*|}"
  code=$(curl -s -o /dev/null -w '%{http_code}' -A "$ua/1.0" "$BASE/")
  case "$want:$code" in
    BLOCK:40[0-9]|ALLOW:200) status="ok" ;;
    *) status="MISMATCH"; fail=1 ;;
  esac
  printf '%-18s want=%-5s got=%-3s  %s\n' "$ua" "$want" "$code" "$status"
done
exit "$fail"

Edit the BOTS array to match the policy you actually want, then run it in CI or a cron. The point is that the expectations are declared in one place and checked, instead of living in someone's memory.

Two failure modes it catches immediately:

ClaudeBot returns 200. Your rule is not running. Usual causes: virtual robots.txt, a CDN answering in front of the origin rule, or a host that ignores .htaccess.
Claude-SearchBot returns 403. Your pattern is too broad. A regex of Claude matches all three Anthropic tokens, so you refused training and deleted yourself from Claude's answers in one line. ## 4. Fix the too-broad pattern

Anchor on full tokens, one per bot you actually mean. The clever compact regex is how the over-block happens.

apache (.htaccess):

<IfModule mod_rewrite.c>
  RewriteEngine On
  # training crawlers only - retrieval bots deliberately absent
  RewriteCond %{HTTP_USER_AGENT} (ClaudeBot|GPTBot|PerplexityBot|CCBot) [NC]
  RewriteRule .* - [F,L]
</IfModule>

nginx:

map $http_user_agent $ai_training_bot {
    default              0;
    "~*ClaudeBot"        1;
    "~*GPTBot"           1;
    "~*PerplexityBot"    1;
    "~*CCBot"            1;
}

server {
    if ($ai_training_bot) { return 403; }
}

Note what is not in either list: no Claude-SearchBot, no OAI-SearchBot, no Googlebot. That omission is the policy.

5. Verify the caller is who it claims

The user-agent string is public and forgeable, so treat it as a claim rather than an identity. Anthropic and OpenAI both publish crawler IP ranges, which makes the claim checkable: a request presenting as ClaudeBot from an address outside the published set is provably lying.

# pull the IPs your log attributed to a given bot, then check them against
# the vendor's published prefixes before trusting the label
awk '/ClaudeBot/ {print $1}' /var/log/nginx/access.log | sort -u | head -50

Confirm the current endpoint and JSON schema for each vendor's published ranges before wiring this into automation. Both vendors have changed the format at least once.

Where a plugin earns its place, and where it does not

Everything above is a hand-maintained rule set, and hand-maintained is a real option: a competent sysadmin's nginx map and a plugin-managed rule produce the identical 403. The difference is upkeep. Tokens get added, renamed, and deprecated, syntax differs across Apache and nginx, and a botched .htaccess edit takes the whole site down rather than one rule.

That maintenance gap is the honest case for something like WP Ghost, which keeps a list of 30+ AI and scraper user agents with per-bot toggles and applies them at a server-level firewall ahead of PHP, or for equivalent edge-managed bot rules if you already run everything through a CDN. Pick based on how many sites you maintain and who is responsible when a vendor adds a fourth bot.

What none of them do, including that one: unmask a scraper that lies. A user-agent policy governs the population that identifies itself. A residential proxy pool presenting a Chrome string is a rate-limiting and traffic-shaping problem with a different toolkit, and any tool advertising "blocks bad bots" as one checkbox is collapsing two populations that need different answers. Consent enforcement and extraction defence are separate projects; the audit above is squarely the first one.

WordPress path security: return 404 before PHP runs (Apache + nginx)

Calin V. — Wed, 22 Jul 2026 16:32:34 +0000

Every default WordPress install answers the same handful of requests at the same paths. That's what lets one script attack hundreds of thousands of sites: /wp-login.php, /wp-admin/, /?author=1, /xmlrpc.php, /wp-content/uploads/. Same coordinates everywhere.

Path security is moving or rejecting those predictable paths at the rewrite layer, so the request returns 404 before PHP loads. Not a PHP firewall that boots WordPress and then decides to block. The server's rewrite rules (Apache mod_rewrite, nginx location blocks) answer first.

It matters because the targeting is automated and fast. Per Patchstack's State of WordPress Security in 2026, 91% of the 11,334 vulns disclosed in 2025 were in plugins, and heavily-exploited ones are hit within 6h (20%), 24h (45%), and 7 days (70%) of disclosure. You reject the recon request, the exploit request behind it never arrives.

Two rules before touching anything: do the login-path move last, and verify every change from outside with curl, not from a settings screen.

0. Watch what a bot sees

for p in "wp-login.php" "wp-admin/" "?author=1" "xmlrpc.php" "wp-content/uploads/"; do
  code=$(curl -s -o /dev/null -w "%{http_code}" "https://example.com/${p}")
  printf "%-22s -> %s\n" "$p" "$code"
done

Whatever returns 200/301/302 is a coordinate the script already has. The goal below is to turn those into 404/403.

1. Kill directory listing (zero lockout risk, do it first)

If /wp-content/uploads/ has no index file, the server lists every file in it: PDFs, invoices, a stray DB export. Close it.

# .htaccess (Apache / LiteSpeed)
Options -Indexes

# nginx server/location block
autoindex off;

Verify:

curl -s -o /dev/null -w "%{http_code}\n" "https://example.com/wp-content/uploads/"  # want 403, not a file list

2. Reject path traversal and sensitive-file requests

Path traversal (CWE-22) uses ../ sequences to climb out of a plugin's directory and read files like wp-config.php. You can't patch someone else's plugin from here, but you can reject the malformed request at the edge of your own server so it never reaches the plugin's PHP.

# .htaccess: block encoded/literal traversal and dotfile probes
RewriteEngine On
RewriteCond %{QUERY_STRING} (\.\./|\.\.%2f|%2e%2e) [NC]
RewriteRule ^ - [F]

# deny direct hits on sensitive files
<FilesMatch "^(wp-config\.php|readme\.html|license\.txt|xmlrpc\.php)$">
  Require all denied
</FilesMatch>

location ~* (\.\./|\.\.%2f|%2e%2e) { return 403; }
location = /xmlrpc.php { deny all; }
location = /readme.html { deny all; }

This is surface reduction, not a patch. It buys the window until the plugin update lands. Update anyway.

3. Suppress full path disclosure

An error that prints /home/user/public_html/wp-content/... hands a traversal attempt its map. Turn off public debug output so error paths never render.

// wp-config.php
define('WP_DEBUG', false);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

And make sure the log itself isn't served:

<Files debug.log>
  Require all denied
</Files>

4. Close author enumeration

/?author=1 redirects to the author slug (a real username), and the REST API lists users. A known username makes credential stuffing easier, and 88% of web-app attacks used stolen credentials (Verizon 2025 DBIR).

# .htaccess
RewriteCond %{QUERY_STRING} (^|&)author=([0-9]+) [NC]
RewriteRule ^ - [F]

// close the REST users route for anonymous requests
add_filter('rest_endpoints', function ($e) {
    unset($e['/wp/v2/users'], $e['/wp/v2/users/(?P<id>[\d]+)']);
    return $e;
});

5. Move the login path (LAST, with a rollback staged)

This is the highest-impact change and the one most likely to lock you out, because plugins generate their own login links (WooCommerce account pages, membership flows, password-reset emails, builder previews). Miss one reference and you get a redirect loop.

Stage the rollback before you make the change:

cp .htaccess .htaccess.bak
# recovery if you lock yourself out:
#   restore over SFTP/SSH, then flush caches
#   mv .htaccess.bak .htaccess && wp cache flush

The mechanism: route your chosen path to the login handler and return 404 for the default.

# .htaccess (illustrative; keep every generated login link in sync)
RewriteRule ^secret-door/?$ /wp-login.php [QSA,L]
RewriteCond %{REQUEST_URI} ^/(wp-login\.php|wp-admin)(/|$) [NC]
RewriteCond %{HTTP_COOKIE} !wordpress_logged_in [NC]
RewriteRule ^ - [R=404,L]

nginx equivalent lives in the server config and needs a reload:

location = /secret-door { try_files /wp-login.php =404; }
location ~* ^/(wp-login\.php|wp-admin) {
  # allow logged-in sessions through your real path; 404 the rest
  return 404;
}

Doing this by hand means owning every hard-coded reference and re-testing on each plugin update, which is exactly why many people hand the rewrites to a login-path/hardening plugin instead. Either way, keep the old admin tab open until the new path is confirmed.

Re-run the baseline

curl -s -o /dev/null -w "wp-login.php  -> %{http_code}\n" "https://example.com/wp-login.php"   # 404
curl -s -o /dev/null -w "wp-admin/     -> %{http_code}\n" "https://example.com/wp-admin/"       # 404/302 to 404
curl -s -o /dev/null -w "author=1      -> %{http_code}\n" "https://example.com/?author=1"        # 403
curl -s -o /dev/null -w "uploads/      -> %{http_code}\n" "https://example.com/wp-content/uploads/" # 403
curl -s -o /dev/null -w "xmlrpc.php    -> %{http_code}\n" "https://example.com/xmlrpc.php"        # 403

"Isn't this security through obscurity?"

No. Obscurity leaves the resource in place and bets nobody looks hard enough. A 404 at the rewrite layer means the request never reaches code that can act on it: the login handler doesn't run, the plugin endpoint doesn't load. The automated chain depends on predictable coordinates, so removing the coordinates breaks it at step one. That's deleting attack surface, not covering it.

And it doesn't replace a scanner. Path security breaks recon; it doesn't disinfect an infected site. If the baseline in step 0 already looked wrong, clean first, then harden.

On nginx-managed hosting, how do you handle the config reload for path rules without shell access — host automation, a plugin that writes the vhost, or something else? Curious what's actually working for people on SiteGround/Kinsta-style setups.

Prevent WordPress hacks by reading your own access log

Calin V. — Wed, 08 Jul 2026 09:23:10 +0000

WordPress hack prevention is not a product you install after a breach. It is the boring work you do before one, and almost all of it is a reaction to traffic that is already hitting your site right now. Open your access log and you can watch the first stage of nearly every WordPress compromise happen in real time: a bot confirming you run WordPress, listing your plugins, and testing your login. This post reads that log line by line, then breaks the attack chain stage by stage with configuration you already control.

I run WordPress security across a portfolio of sites at Squirrly, and the single most useful habit I picked up is treating the access log as a live feed of the reconnaissance stage instead of a forensic artifact I only open after something goes wrong. Detection tools tell you an attack happened. The log tells you it is happening, which is the only time prevention is cheap.

The three-stage chain, and why the first stage is the one to break

Automated WordPress attacks almost always run the same three stages: reconnaissance, then exploitation, then persistence. Reconnaissance is the bot requesting predictable paths to confirm WordPress and enumerate versions. Exploitation is a stolen credential or an unpatched vulnerability. Persistence is the backdoor it leaves so it can come back. Three stages means three places to cut the chain, and the cheapest cut is the first one, because a probe that returns nothing useful never advances to exploitation.

The reason prevention beats a patch-faster strategy: the exploitation window has collapsed. In Patchstack's State of WordPress Security in 2026, among heavily exploited vulnerabilities, 20% were attacked within six hours of public disclosure, 45% within 24 hours, and 70% within seven days. Highly exploitable vulnerabilities rose 113% year over year. You cannot hand-patch faster than a six-hour window across every plugin you run. You can make sure the vulnerable thing is not reachable in the first place.

Read the reconnaissance in your access log

Start by quantifying what is already probing you. On nginx combined logs, the request path is field 7, so this counts the top recon targets over whatever the log covers:

# Top probed WordPress paths
awk '{print $7}' /var/log/nginx/access.log \
  | grep -Ei 'wp-login|xmlrpc|wp-admin|author=|wp-json/wp/v2/users|wp-content/plugins' \
  | sort | uniq -c | sort -rn | head -20

Then look specifically at credential pressure. A failed WordPress login is a POST /wp-login.php that returns 200 (the form re-renders); a success returns 302. So the busiest source IPs on 200-POSTs are your brute-force traffic:

# Top IPs hammering the login form (failed attempts)
grep 'POST /wp-login.php' /var/log/nginx/access.log \
  | awk '$9 == 200 {print $1}' \
  | sort | uniq -c | sort -rn | head

On the sites I watch, those two commands routinely turn up hundreds to thousands of hits a day on a site nobody is deliberately targeting. That is the point worth internalizing: it is not personal. WordPress powers roughly 43% of the web (W3Techs), which makes it the largest automated-attack surface online, and Sophos/Hostinger figures put the number of WordPress sites hacked per day around 13,000. Bots probe by IP range, not by whether your content is worth stealing.

Stage one: make reconnaissance return nothing

The recon stage depends on predictability. The login is always at /wp-login.php, the admin at /wp-admin/, usernames leak from /?author=1 and the REST API. Change those defaults at the rewrite layer and the probe returns a 404 before PHP loads, so the site stops confirming itself as a target.

The lowest-risk wins first. Reject author enumeration and close the REST user list:

# .htaccess — reject /?author=N enumeration
RewriteEngine On
RewriteCond %{QUERY_STRING} (^|&)author=([0-9]+) [NC]
RewriteRule ^ - [F]

// mu-plugin: drop the REST users endpoints for anonymous requests
add_filter('rest_endpoints', function ($endpoints) {
    unset($endpoints['/wp/v2/users']);
    unset($endpoints['/wp/v2/users/(?P<id>[\d]+)']);
    return $endpoints;
});

Relocating the login path is the highest-impact recon cut, and also the one most likely to lock you out if you fumble it. Doing it purely by hand means maintaining rewrite rules plus patching every hard-coded reference (auth emails, cached pages, some plugins), which is why most people run a login-path/hardening plugin for this rather than owning the rewrites. Whichever route you take, keep the old session open and confirm the new URL works before you close the tab. This is where the tired "isn't that just security through obscurity?" objection shows up, and the honest answer is no: a 404 at the rewrite layer means the login code never executes. You are not covering a door, you are removing it from the map the bots are reading.

Stage two: break credential exploitation

Reconnaissance that survives leads straight to credentials, because that is where the actual break-ins are. The Verizon 2025 Data Breach Investigations Report found that 88% of Basic Web Application attacks involved stolen credentials, and that credential abuse opened 22% of all breaches. On WordPress that is the brute-force and credential-stuffing traffic your second log command surfaced.

Rate-limit the login at the server layer so the flood never reaches PHP. In nginx:

# http { } block
limit_req_zone $binary_remote_addr zone=wplogin:10m rate=20r/m;

# server { } block
location = /wp-login.php {
    limit_req zone=wplogin burst=5 nodelay;
    include fastcgi_params;
    fastcgi_pass unix:/run/php/php-fpm.sock;
}

Then jail the repeat offenders with fail2ban so they stop consuming any resources at all:

# /etc/fail2ban/filter.d/wordpress-auth.conf
[Definition]
failregex = ^<HOST> .* "POST /wp-login\.php.*" 200

# /etc/fail2ban/jail.d/wordpress.conf
[wordpress-auth]
enabled  = true
port     = http,https
filter   = wordpress-auth
logpath  = /var/log/nginx/access.log
maxretry = 5
findtime = 600
bantime  = 3600

Rate-limiting and banning slow the noise. What actually neutralizes a stolen password is a second factor, so move real users off password-only logins. A passkey (FIDO2/WebAuthn) binds the cryptographic challenge to your domain, so a credential phished on a lookalike site cannot be replayed against yours. TOTP is a solid fallback where passkeys are not yet an option. The goal is simple: make a correct password insufficient on its own, because 88% of the attacks in the DBIR data are betting it is sufficient.

Stage three: make persistence hard, and detect what slips through

If exploitation still lands, the attacker wants to stay. Two config lines remove the easiest persistence routes:

// wp-config.php
define('DISALLOW_FILE_EDIT', true);  // no theme/plugin editor in the dashboard
define('DISALLOW_FILE_MODS', true);  // no plugin/theme install or update from the dashboard

DISALLOW_FILE_MODS also blocks dashboard updates, so use it where you deploy code through git or CI rather than clicking Update. On sites where that is too strict, keep DISALLOW_FILE_EDIT alone.

The uploads directory is the classic backdoor drop. It should never execute PHP:

location ~* /wp-content/uploads/.*\.php$ { deny all; }

# wp-content/uploads/.htaccess
<FilesMatch "\.php$">
  Require all denied
</FilesMatch>

And a cron that flags PHP where PHP should not be turns persistence into something you notice in hours, not weeks:

# Alert on unexpected PHP under uploads
find wp-content/uploads -name '*.php' -type f -printf '%p\n'

This is the seam where prevention hands off to scanning, and it is worth being honest about it.

The honest limit: prevention is not a scanner

Everything above reduces what an attacker can reach. None of it disinfects a site that is already compromised, and none of it catches malware that arrives through a channel you did not harden, like a legitimate admin session gone bad or a supply-chain update. That is a malware scanner's job. Prevention keeps a clean site clean; scanning is the safety net for what slips through. Run both, weighted toward prevention, and do not confuse one for the other.

There is a reason to weight toward prevention beyond philosophy. When Patchstack pentested common defences in 2025 (internal WAFs, Cloudflare, Imunify360, ModSecurity) against real WordPress exploits, those tools blocked only 12% of attacks on known-exploited vulnerabilities, rising to 26% on a broader test. The Hostinger/Sophos figure puts the share of WordPress exploits bypassing standard hosting firewalls at 87.8%. If your plan is "the host handles it," the data says the host is catching about a quarter. The cheapest quarter to add back is the one you cut at the recon stage, before anything is running.

A minimal prevention baseline

If you do nothing else this week, do these five, in order, verifying after each:

Reject author enumeration and close the REST user endpoints.
Rate-limit /wp-login.php at the server layer.
Add fail2ban for repeat login offenders.
Move admin accounts to a second factor (passkey, then TOTP).
Deny PHP execution under wp-content/uploads/ and turn off the file editor. The surprising thing, every time I do this for a site that just got cleaned up, is how little of it is clever. It is an afternoon of config against traffic that was already in the log. The industry compilations put average WordPress hack recovery around $14,500 once you count downtime and lost rankings. The afternoon is cheaper.

What does your POST /wp-login.php count look like right now if you run that second command? Curious what a normal day looks like across other people's stacks, and what you rate-limit versus ban outright.

Renaming wp-login isn't the same as making wp-admin disappear

Calin V. — Tue, 09 Jun 2026 16:00:40 +0000

"How do I hide wp-admin" is one of the most-searched WordPress security questions, and most answers give the same advice: install a plugin that renames your login URL. That advice isn't wrong. It's just answering a smaller question than the one being asked.

Renaming /wp-login.php to /my-login moves the login form. It does not change what answers at the old path, what your plugin folders advertise, or what your home page tells a scanner about the stack underneath. If your only problem is the password-guessing bot hammering the default form, a renamer solves it. If your problem is "stop my site from being identified and targeted as WordPress," you've solved maybe a third of it.

Here are the three leaks a login rename leaves open.

Leak 1: the old path still costs a full WordPress boot

When a login-URL renamer "blocks" the default path, the request to /wp-login.php still loads WordPress. PHP starts, the plugin stack initializes, and only then does the plugin decide to return a 404 to the logged-out visitor.

The visitor sees a 404. Your server still did the work of booting WordPress to produce it.

On a quiet site, nobody notices. On a site taking tens of thousands of probes a day, that's tens of thousands of full WordPress boots spent generating 404s. Your security dashboard's "attempts blocked" counter looks great. Your CPU graph disagrees.

The architectural alternative is to reject the request at the rewrite layer, before PHP runs:

# Apache .htaccess — reject the default login path at the server level
<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{REQUEST_URI} ^/(wp-login\.php|wp-admin) [NC]
  RewriteCond %{HTTP_COOKIE} !wordpress_logged_in [NC]
  RewriteRule .* - [R=404,L]
</IfModule>

# nginx — same idea, requires a config reload after change
location ~* ^/(wp-login\.php|wp-admin) {
    if ($http_cookie !~* "wordpress_logged_in") { return 404; }
}

The probe to the old path returns 404 from the server, WordPress never loads, and the request costs almost nothing. Same 404 the visitor sees, very different cost on your side, and anything that would have exploited a PHP-level flaw never reaches PHP. (Hand-rolling this is fine on a single site; the edge cases — AJAX on the front end, REST callbacks, WooCommerce account pages — are why people reach for a maintained tool once they run more than one site.)

Leak 2: your plugin and theme folders still announce the stack

Change the login URL and a bot that can't find the form doesn't quit your site. It pivots. The next cheap move is to fingerprint what you run, because a known-vulnerable plugin is a better door than a guessed password.

That fingerprinting reads paths your own HTML hands over:

/wp-content/plugins/woocommerce/
/wp-content/plugins/elementor/
/wp-content/themes/your-theme/style.css?ver=2.4.1
/wp-content/plugins/some-plugin/readme.txt   <-  version in plain text

None of that is behind the login. It's in the page source of your home page. Patchstack counted 11,334 WordPress vulnerabilities disclosed in 2025, and 91% of them live in plugins rather than core. A scanner that reads your plugin inventory off the page source matches it against that disclosure list in milliseconds. Renaming the login form does nothing here, because the inventory never leaked through the login.

Closing this leak means relocating the plugin and theme paths and stripping the version strings, so the same scanner reads asset URLs that carry no wp-content, no plugin slug, and no version to match.

Leak 3: REST, AJAX, and the generator tag keep talking

Even with the form moved and the plugin paths changed, WordPress has a few other mouths:

<meta name="generator" content="WordPress 6.x" />
<link rel="https://api.w.org/" href="https://example.com/wp-json/" />

The wp-json REST API answers at its canonical route and will, by default, enumerate usernames through /wp-json/wp/v2/users. admin-ajax.php sits at its default path. CMS detectors like Wappalyzer and BuiltWith key on exactly these signals. A login-URL renamer touches none of them, which is why a site with a renamed login but a default REST route still reads as unambiguous WordPress.

The honest comparison

Capability	Login-URL renamer (e.g. WPS Hide Login)	Path + fingerprint layer
Changes the login slug	Yes	Yes
Old path rejected before PHP loads	No (WordPress boots, then 404s)	Yes
Relocates wp-content / plugin / theme paths	No	Yes
Removes generator, `?ver=`, RSD from output	No	Yes
Restricts wp-json username enumeration	No	Yes
Footprint	Very light, single-purpose	Heavier, broad config
Free tier	Yes	Yes

A renamer wins the footprint row honestly. All-in-One Security sits in between: it renames the login URL and adds a .htaccess firewall, but does less with the broader paths and the HTML fingerprint. None of this makes a renamer "bad." It makes it a different size of tool than the question usually wants.

How to test what you actually changed

One mistake to avoid: don't check your own site with Wappalyzer or BuiltWith while logged into wp-admin. The admin screens emit WordPress signals you can't strip, so you'll always see "WordPress" and conclude nothing worked. Test in a clean incognito window, logged out, and check:

# Generator tag and REST link still present?
curl -s https://example.com/ | grep -iE 'generator|api.w.org|/wp-json'

# Default login path still booting WordPress instead of a server 404?
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/wp-login.php

# Username enumeration via REST still open?
curl -s https://example.com/wp-json/wp/v2/users

If the first command returns matches, your fingerprint is still readable. If the second returns 200 (or a slow 404), PHP is still booting for that path. If the third returns a user list, enumeration is open. A login rename leaves all three exactly as they were.

Renaming the form is a reasonable first move. Just measure it for what it is: one URL moved, not a stack reconfigured.

What does your current setup return for those three curl checks — and were you surprised?

Wordfence vs WP Ghost: a layer-by-layer comparison

Calin V. — Sat, 06 Jun 2026 14:46:17 +0000

I run engineering at Squirrly, where we operate a portfolio of WordPress sites. The "Wordfence or WP Ghost?" question comes up constantly, and it's framed wrong almost every time. They're not alternatives. They guard different layers. Here's the version with config examples instead of a marketing table.

The one-paragraph answer

Wordfence is a scanner plus an in-application firewall. It runs as PHP inside WordPress, inspects requests after they've reached the application, and scans files on disk for known-bad signatures. WP Ghost works one layer earlier: it changes default paths and rejects malicious request patterns at the rewrite layer, before PHP loads. Detection and cleanup on one side, attack-surface reduction on the other. On most production sites you want both.

Where the request actually goes

A request to your WordPress site passes through a stack of layers:

client
  → network layer        (Cloudflare / host firewall: traffic shaping, DDoS)
  → server layer         (.htaccess / nginx rewrite rules: routing decisions)   ← WP Ghost
  → application layer     (WordPress boots, plugins init, endpoint firewall)     ← Wordfence
  → file system          (on-disk files; malware scanner reads here)            ← Wordfence
  → backups              (UpdraftPlus / host snapshots: recovery)

The position is the whole point. Wordfence's endpoint firewall is PHP code, so by the time it inspects a request, WordPress has already loaded. WP Ghost's 7G/8G rules are rewrite directives that execute before the PHP interpreter is invoked at all.

What that difference costs (and saves)

Consider a bot brute-forcing the default login path. With an in-PHP firewall alone:

GET /wp-login.php  →  Apache/nginx hands request to PHP
                   →  WordPress core loads
                   →  plugin stack initializes (including the firewall plugin)
                   →  firewall evaluates, rate-limits, returns 403

Every blocked probe still paid for a full WordPress boot. With a rewrite-layer path change, the default path simply isn't served:

GET /wp-login.php  →  rewrite rule matches  →  404, PHP never invoked

The script gets a 404, doesn't adapt (these bots don't pivot to a renamed path), and moves to the next domain in its queue. On bot-heavy sites the net effect is a measurable load reduction, because the rejected requests never reach PHP.

The fingerprint problem

Attack chains usually start with reconnaissance: confirm it's WordPress, enumerate plugins, match against a CVE list. WordPress advertises itself by default:

<meta name="generator" content="WordPress 6.x" />
<link rel="https://api.w.org/" href="https://example.com/wp-json/" />
<link rel="stylesheet" href="https://example.com/wp-content/plugins/some-plugin/style.css?ver=2.1" />

Each of those is a signal a classifier like Wappalyzer reads. WP Ghost removes them from output (generator tag, RSD header, version strings, /wp-json/ link) and changes the /wp-content/ and plugin paths in asset URLs. The classifier returns "unidentified CMS," and the plugin-enumeration step that feeds CVE targeting comes back empty. This matters in context: Patchstack's 2026 report counted 11,334 WordPress vulnerabilities disclosed in 2025 (a 42% YoY increase), 91% of them in plugins. Most of those exploits start by confirming the plugin is installed.

Wordfence does not do any of this path-changing or fingerprint removal. That's not a knock; it's a different job.

What Wordfence does that WP Ghost doesn't

Be honest or don't write the comparison. Wordfence's malware scanner, file-integrity monitoring, live traffic view, and Premium threat-intel feed are genuinely strong. WP Ghost scans nothing. If a file on disk is already infected, or was planted before you hardened the site, WP Ghost won't find it. The scanner will. With WPMayor's reporting putting the disclosure-to-exploitation window around five hours, the Premium rule feed is a real asset on high-value sites.

Verifying the prevention layer actually works

After changing paths, confirm the default endpoints are gone and the new ones respond:

# default login should now 404
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/wp-login.php
# expect: 404

# fingerprint check: generator tag should be absent
curl -s https://example.com/ | grep -i 'name="generator"'
# expect: no output

# new login path should serve the form (replace with your configured path)
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/your-new-login/
# expect: 200

If you're on nginx, remember the rewrite changes need a config reload (nginx -s reload or your host's equivalent). Apache and LiteSpeed pick up .htaccess changes without a reload.

The honest overlap

Both tools do 2FA, brute-force rate limiting, and basic hardening. Don't double-configure rate limiting; pick one. The one authentication edge worth calling out: WP Ghost ships passkey 2FA (FIDO2 / WebAuthn: Face ID, Touch ID, Windows Hello, hardware keys) in its free tier. Passkeys are phishing-resistant because the WebAuthn challenge is bound to the origin, so a phished credential can't be replayed against your domain.

The stack I'd actually run

Cloudflare (free)         → network noise + DDoS
WP Ghost (free)           → path changes, fingerprint removal, 7G/8G rewrite firewall
Wordfence (free or Prem)  → malware scan, file integrity, live traffic
UpdraftPlus               → backups / recovery

Roughly: WP Ghost lowers what reaches the application, Wordfence catches what gets through and what's already there, backups get you home if both fail.

TL;DR

Wordfence detects and cleans. WP Ghost prevents and relocates. They sit on different layers and the feature rows barely overlap, so "vs" is the wrong framing. Run the scanner for eyes on disk, run the path-changer for a smaller front door.

Question for the comments: if you run both, did you notice a server-load change after moving the login and admin paths off the defaults? I'm curious how consistent the drop is across different hosts.

WP Ghost has a free version on wordpress.org.

43 WordPress Security Data Points That Should Change How You Build Sites in 2026

Calin V. — Fri, 17 Apr 2026 05:24:49 +0000

Every year, Patchstack publishes a whitepaper on the state of WordPress security. Every year, the numbers get worse. The 2026 edition dropped on February 25, and the headline numbers are hard to ignore.

This post pulls together 43 verified data points from 18 original research sources into the picture you need if you build, manage, or host WordPress sites. No speculation, no fear marketing, just numbers and what they mean for your workflow.

The full sourced version with inline citations lives on the WP Ghost research page. This is the developer-focused summary.

The Four Numbers That Define WordPress Security Right Now

Before getting into the breakdown, these four stats frame everything that follows:

11,334 new WordPress vulnerabilities recorded in 2025, a 42% increase year-on-year
~13,000 WordPress sites hacked per day, roughly 4.7 million annually
5 hours, the weighted median from vulnerability disclosure to mass exploitation
87.8% of WordPress-specific exploits bypass standard hosting firewalls

If you only remember four numbers from this post, those are the ones.

How Large Is the Attack Surface?

WordPress powers 43.5% of all websites on the internet (Hostinger, 2026). That's not a niche CMS. That's nearly half the web running on the same stack, with the same default paths, the same directory structure, and the same plugin ecosystem.

From an attacker's perspective, the economics are straightforward. Write one scanner, point it at the internet, and nearly every other site you hit is WordPress. The attacks don't need to be clever. They just need to be automated and fast.

Wordfence, the most widely deployed WordPress security plugin, blocks 55 million exploit attempts and over 6.4 billion brute force attacks every single month across its network (TDW Digital, 2025). That's the permanent baseline, not a spike.

Most of those attacks are not targeted. Bots scan millions of sites daily looking for the same fingerprints: a /wp-login.php path, an exposed version number in a meta tag, a plugin signature in the page source. They are not interested in your site specifically. They are interested in any site that looks like a standard WordPress installation.

11,334 Vulnerabilities: Where Are They Coming From?

Patchstack confirmed a record year. Not close to a record. Definitively the worst year on record, by a wide margin.

The growth over three years tells the story:

Year	Vulnerabilities	Change
2023	~5,900	baseline
2024	~7,966	+35%
2025	11,334	+42%

And Q1 2026 is not slowing down. In the first week of January 2026 alone, 333 new vulnerabilities were disclosed, with 120 of them having no patch when they went public (WebHostMost, Mar 2026). The weekly average heading into 2026 is 250+ plugin vulnerabilities per week, roughly 36 per day.

It's Not Core

The WordPress core team found exactly two vulnerabilities in all of 2025 (Patchstack 2026). Two.

The problem is the plugin ecosystem:

91% of vulnerabilities come from plugins
6% from themes
2% from core (those two)

Every plugin you install is a potential entry point. The average WordPress installation runs 20 to 30 plugins. The math is not complicated.

The Severity Jump

Highly exploitable vulnerabilities, the ones attackers weaponize at scale, increased by 113% year-on-year in 2025 (The Repository / Patchstack, Mar 2026). More high-severity CVEs were found in 2025 than in the previous two years combined.

AI-Generated Plugins Are Making It Worse

Patchstack's 2026 report specifically calls out "vibe coding," where developers use LLMs to generate plugin code and ship it without being able to audit what the model wrote. When the person shipping the code can't review it for security problems, vulnerabilities go live silently. This trend is accelerating, not stabilizing.

The 5-Hour Problem

Here is the number from Patchstack's 2026 report that fundamentally changes how you should think about WordPress security:

"The weighted median time to first mass exploitation was five hours."

Patchstack, State of WordPress Security in 2026

Five hours from public disclosure to active mass exploitation.

The traditional advice, "keep your plugins updated," assumes you have time to react. For heavily targeted vulnerabilities, you often don't.

The exploitation timeline breaks down like this:

Window	What happens
0-5 hours	Median first mass exploitation attempt. Automated scanners watch disclosure feeds and deploy exploit code within hours.
Within 6 hours	20% of top-targeted vulnerabilities are actively exploited.
Within 24 hours	45%. By the time most site owners read about it in a newsletter, attacks have been running for a full day.
Within 7 days	70%. Roughly when most people get around to clicking that update notification they've been ignoring.

And what makes the 5-hour window even more dangerous:

46% of vulnerabilities had no patch available at the time of public disclosure (WP Edition / Patchstack, Feb 2026). There is no update to apply. The vulnerability is public, documented, actively scanned for, and the plugin is still broken.

Why? Because 52% of plugin developers do not patch before disclosure (Patchstack via Xictron, 2026). The researcher found the bug, reported it responsibly, waited the standard disclosure window, published, and the developer still hadn't shipped a fix.

Patchstack says it plainly: "Regular plugin updates are the second line of defence, but as attackers weaponize new vulnerabilities within mere hours, this is not a viable defence."

Where Do Hackers Actually Get In?

The vulnerability type distribution for 2025-2026:

Attack Type	Share	Auth Required?
Cross-Site Scripting (XSS)	Dominant (~35-39%)	Often none
Cross-Site Request Forgery (CSRF)	~19%	Existing session
Local File Inclusion (LFI)	~12.6%	Often none
Broken Access Control	~10.9%	Low-privilege
SQL Injection	~7.2%	Often none

XSS dominates because it's easy to introduce in plugin code and notoriously difficult to patch completely.

The critical detail: 57% of vulnerabilities in H1 2025 required no authentication whatsoever (Patchstack Mid-Year 2025). No login needed. No password to steal. Just a vulnerable plugin, installed and active.

What Attackers Leave Behind

Sucuri's data on what's found on compromised WordPress sites (Sucuri via Hostinger, 2026):

72.7% contain active malware
69.6% have unauthorized backdoors, persistent access the attacker can use later
46.7% have SEO spam injected, hidden keyword-stuffed content that triggers Google penalties
8.1% have phishing pages embedded within the site

The 2026 Patchstack and Monarx report adds an important shift: attackers are now injecting code directly into legitimate WordPress core, plugin, and theme files rather than dropping standalone malicious files. The traditional "scan and delete" approach to malware removal misses this entirely (The Repository, Mar 2026).

The Login Page Problem

In 2023, Wordfence blocked over 100 billion credential stuffing attacks from 74 million unique IP addresses. The vast majority targeted the standard /wp-login.php and /wp-admin paths. 81% of hacked WordPress sites involved weak or stolen passwords as a contributing factor (Sucuri and Wordfence via HowToWP).

If your login page is at the default URL, you are absorbing every automated attack that knows where to look.

Why Hosting Firewalls Are Not Enough

Managed WordPress hosting is expensive and comes with security messaging all over the pricing page. Those server-level firewalls are doing something, just not nearly enough.

87.8% of WordPress-specific exploits bypass standard hosting defenses (Patchstack via Xictron, 2026). Standard hosting defenses block only about 26% of WordPress-targeted attacks.

The reason is structural. Network and server firewalls were designed to block broad categories of malicious traffic: DDoS floods, port scans, known malicious IPs. They were not designed to understand the application-specific semantics of a stored XSS vulnerability in version 3.4.1 of a specific WordPress plugin. That requires application-layer intelligence.

Patchstack's 2026 conclusion: "In 2026, everybody needs deep visibility into what their websites are made of and put automated security measures in place to mitigate new security vulnerabilities in less than five hours."

The EU Cyber Resilience Act

By September 2026, all plugin and theme developers distributing software to EU users must have vulnerability disclosure programs in place by law. Whether this will meaningfully reduce the 52% non-patch-before-disclosure rate remains to be seen (Patchstack 2025 Whitepaper).

What Does a WordPress Hack Actually Cost?

The headline figure: $14,500 average total recovery cost for a small business (Colorlib, Xictron 2026).

That includes malware removal, emergency developer time, downtime, lost revenue, and the months of SEO work required to undo injected spam links and Google manual penalties. Against approximately $8/month for active protection, the math is not close.

The Melapress 2025 Security Survey found that 59.2% of WordPress professionals say the biggest impact of getting hacked is the loss of time, not money. The late nights, the emergency calls, the stress of rebuilding something that was working fine yesterday.

A real scenario: A WooCommerce store gets flagged by Google on a Friday afternoon. Malware was redirecting the checkout page to a phishing site. By Monday morning, it's been three days. Google Search Console has a manual penalty notice. PayPal suspended the account. Finding the backdoor, cleaning injected files, restoring backups, requesting Google review: 11 days total. $4,200 in lost orders. $1,200 for emergency cleanup. $5,400 total. The security plugin subscription they had skipped: $96 per year.

Are WordPress Site Owners Actually Prepared?

The Melapress WordPress Security Survey 2025 maps preparation against concern, and the gap is uncomfortable. Site owners rate their concern at 7.8 out of 10 on average. Two-thirds scored it 8 or higher.

And yet:

Only 27% have a breach recovery plan. More than 73% have no documented response to "what do we do when this happens?"
Only 27% implement team security training
Among those who had experienced account compromises, 30% still hadn't implemented any user account security controls
Only 59% use a WordPress activity log to detect suspicious behavior
Web designers and developers, the professionals who build WordPress sites, are the least likely to use automatic updates, at 32% and 33% respectively

There's also an outsourcing gap: 31% of in-house managers have a recovery plan, but only 13% of those relying on third parties do (Melapress, Oct 2025).

If you've outsourced security, ask your provider directly: what is the plan if we get hacked?

What Does the Data Say Actually Works?

The genuinely good news: the overwhelming majority of WordPress hacks are preventable. OsomStudio's 2026 security analysis estimates that basic security hygiene stops more than 90% of attacks (OsomStudio, 2026).

Most attackers are opportunistic. When a site looks harder to target than average, they move on.

Based on the attack data above, effective WordPress hack prevention works in three layers:

Layer 1: Disappear from Scanners

Automated scanners identify WordPress installations by their fingerprints: version numbers in meta tags, the /wp-login.php path, the readme.html file in root, plugin signatures in source code.

Remove those signals and mass-scanning tools can't confirm you are running WordPress. They move on. This is attack surface reduction as a first defense, and it works against every automated scanner that hasn't already fingerprinted your site.

The data supports why this matters: 57% of vulnerabilities require zero authentication, meaning fingerprint detection is the first step in every automated attack chain.

Tools that do this: WP Ghost (full path security, 115+ features in the free version), WPS Hide Login (login path only), or manual rewrite rules if you prefer to roll your own.

Layer 2: Filter at the Application Layer

What hosting firewalls miss (87.8% of it), an application-layer firewall catches:

8G Firewall rules for SQL injection, XSS, file inclusion, directory traversal
Brute force protection + 2FA to address the 81% of hacks involving credential attacks
XML-RPC and REST API restrictions to close attack surfaces most sites don't need open
Geo-blocking to reduce automated attack volume from high-risk regions
Moving the login page off /wp-login.php, since most automated credential attacks target that path specifically

Tools: WP Ghost (built-in 7G/8G firewall, 2FA with passkeys), Wordfence (endpoint firewall + scanner), Sucuri (cloud WAF), or a combination.

Layer 3: Monitor and Detect

Activity logging, file integrity monitoring, and anomaly alerts are the difference between catching a compromise in hour one and discovering it three months later when Google sends a penalty notice. Given that 69.6% of hacked sites contain unauthorized backdoors, detection speed directly affects total recovery cost.

Tools: WP Ghost Security Threats Log (Premium), Wordfence live traffic, Sucuri audit log, or WP Activity Log.

Three Things You Can Do This Week

If this wall of stats is overwhelming, start here:

1. Audit your plugins

List every plugin on your site. For each one: is it actively maintained? When was the last update? Does your site actually need it? Remove anything unused. Every inactive plugin is an attack surface with zero upside.

2. Check your login URL

If your login page is still at /wp-login.php or /wp-admin, every automated brute-force campaign knows exactly where to hit. Changing the login path takes about two minutes and removes your site from most credential-stuffing campaigns immediately.

3. Write a one-page recovery plan

Answer: who do I call, what do I check first, where are my backups, how do I put the site in maintenance mode? The 73% without a plan make recovery take 3-4x longer, not because they are less capable, but because they are making decisions under stress without a framework.

Summary

According to data compiled from 18 original research sources:

11,334 new WordPress vulnerabilities in 2025, the highest ever, a 42% increase year-on-year (Patchstack, Feb 2026)
~13,000 WordPress sites hacked per day, totaling 4.7 million annually (WPMayor via Sophos)
5 hours median from disclosure to mass exploitation, with 46% of vulnerabilities having no patch at the time of disclosure (Patchstack 2026)
87.8% of WordPress-specific exploits bypass hosting firewalls (Patchstack via Xictron 2026)
$14,500 average recovery cost for a small business, versus approximately $8/month for proactive protection (Colorlib, Xictron 2026)
~90% of attacks are preventable through basic security hygiene (OsomStudio 2026)

The full version with all 43 data points and inline source citations: WordPress Security Statistics 2025-2026

Data sourced from Patchstack 2026 Whitepaper, Patchstack Mid-Year 2025, Wordfence, Sucuri, Melapress 2025 Security Survey, OsomStudio 2026, Hostinger, WPMayor/Sophos, Colorlib, Xictron 2026, TDW Digital 2025, WebHostMost 2026, WP Edition, The Repository/Patchstack, and HowToWP. All numbers verified as of April 2026.

The Real Cost of 1 Hour of WordPress Downtime (It's More Than You Think)

Calin V. — Thu, 09 Apr 2026 13:00:00 +0000

Most WordPress site owners think about downtime the wrong way.

They imagine the damage ending the moment the site comes back online. It doesn't.

The real cost keeps running, in lost sales, developer invoices, search rankings, and customer trust, long after the page loads again.

Here's what one hour of WordPress downtime actually costs, broken down into the four categories that matter.

💸 1. Lost Sales - The Clock Starts Immediately

The moment your site goes down, revenue stops. Every minute a visitor can't reach your store or service page is a potential customer who just went somewhere else.

Atlassian's incident management benchmarks put the cost-per-minute at $427 for small businesses, which adds up to roughly $25,000 over a single hour.

For mid-size businesses, it gets worse. According to a 2024 ITIC survey reported by Shopify, the average cost of one hour of downtime for 90% of midsize and large businesses exceeds $300,000.

Even if your site generates $10,000/month, that's roughly $14 in lost revenue every single minute your site is down, during business hours.

And here's the detail most people miss: if the downtime happens during a product launch, a sale event, or while a paid ad campaign is running, that number multiplies fast.

👨‍💻 2. Developer Fees - The Bill That Arrives After

When a WordPress site goes down due to a hack or security breach, you can't just refresh the page and move on. Someone has to diagnose the problem, clean it up, and close the vulnerability that caused it.

That someone charges by the hour.

According to WPNearMe's 2026 WordPress developer rate analysis, hack recovery and security hardening work sits at the higher end of the $15–$200+/hr range for US-based developers.

And cleanup costs? According to devverx.us, remediation after a security compromise typically runs $1,000–$5,000+ in developer time, plus whatever SEO damage occurred if Google flagged the site as malicious.

That's assuming you catch it quickly and hire someone who does it right the first time.

The reality is messier. As WhatArmy documents, developers often remove visible malicious code without addressing the root vulnerability, and the site gets hacked again a week later, restarting the entire cycle.

📉 3. SEO Hit - The Damage That Outlasts the Downtime

This is the cost most site owners don't see coming. And it's the one that stings longest.

When a site is hacked and starts serving malware, displaying spam pages, or silently redirecting visitors, Google notices. Fast.

What Google actually does

If your site is flagged, users may see a "Deceptive site ahead" warning directly in Chrome before they even reach your site. That's not a minor inconvenience; it's a hard stop for every visitor.

According to Google's own documentation on hacked sites, recovering from a manual penalty can take weeks to months, even after a full cleanup.

The traffic math

A study cited by Moz found that websites with roughly 8.76 hours of annual downtime, the equivalent of 99.9% uptime, can lose up to 20% of organic search traffic.

More severe hacks can result in 50–80% organic traffic loss during the recovery window, as documented by Snazzy Solutions.

The recovery timeline

Per Search Engine Land's penalty guide and multiple SEO sources: recovery from a Google penalty after a hack typically takes 3–6 months, if it recovers at all.

While your rankings are depressed, competitors are capturing the traffic that would have been yours. Some of that audience never comes back.

🤝 4. Loss of Trust - The Cost You Can't Put on an Invoice

Trust is the hardest thing to rebuild after a site goes down, especially when the cause was a hack.

77% of consumers abandon retailers after encountering site errors, according to data cited by Site Qwality's 2025 downtime analysis. Not 77% who complain. 77% who quietly leave and don't come back.

After a downtime or security incident:

Customer acquisition costs rise 15–25%, customers become more skeptical and require more convincing to convert
Conversion rates drop 10–20% in the weeks following the incident
Paid advertising spend often needs to increase 30–50% to compensate for reduced organic traffic and lower conversion rates

(Source: Lagnis downtime cost analysis, 2025)

For agencies managing client sites, the damage goes further: a hacked client site can cost you the relationship entirely, and every referral that client would have sent you. That doesn't show up in any report, but it's very real.

The Full Picture: 1 Hour of WordPress Downtime

Cost Category	Estimated Impact
Lost revenue (1 hour, SMB)	$1,500 – $25,000+
Developer cleanup fees	$1,000 – $5,000+
SEO traffic loss	20–80% organic drop (3–6 months recovery)
Customer trust & conversion loss	15–25% higher acquisition costs
Combined real-world impact	$5,000 – $50,000+

And that's assuming the breach is caught within the hour. Most aren't.

According to ITIC's 2024 Hourly Cost of Downtime Report (cited by EnComputers), 84% of firms cite security as their number one cause of unplanned downtime, and many infections sit undetected for days or weeks.

The Prevention Math Is Simple

Ongoing WordPress security and maintenance typically costs $30–$200/month depending on the level of service.

Compare that to the $5,000–$50,000+ total impact of a single security breach.

This is the core argument behind proactive hack prevention: don't wait for the break-in and then clean up, make the site hard enough to target that bots move on before the attack begins.

A plugin like WP Ghost (Hide My WP Ghost) is built specifically around this logic. Instead of scanning for damage after a breach, it prevents attacks from reaching your site in the first place by:

Hiding the default WordPress paths bots use to fingerprint your CMS (/wp-admin, /wp-login.php, plugin paths)
Blocking malicious traffic with an 8G firewall before it reaches PHP
Enforcing 2FA and brute force protection before an attacker gets near your login
Blocking AI crawlers and scrapers with firewall-level user-agent rules

The plugin's own track record, documented in their knowledge base: in more than 10 years, not a single reported breach on sites that had WP Ghost correctly configured with its core protections active.

The Quick Self-Assessment

Want to know your specific number? Run this calculation:

Monthly revenue ÷ 720 hours = hourly revenue at risk
Hourly revenue × realistic downtime hours = immediate revenue loss
Add: $1,000–$5,000 developer fees
Add: 3–6 months of depressed organic traffic
Add: 15–25% increase in customer acquisition costs

For most businesses, even small ones, the number is uncomfortable.

The question isn't whether you can afford to invest in security. It's whether you can afford not to.