DEV Community: Calin V.

Give Yourself a Dead Man's Switch Before You Harden WordPress

Calin V. — Wed, 16 Sep 2026 17:56:43 +0000

Hardening a WordPress site is a handful of settings and about five minutes of work. The reason people put it off for a year is not the five minutes. It is that one of those settings changes the URL of your login page, and if the rewrite rules do not land the way the interface believes they did, the next thing you see is a 404 where your dashboard used to be.

The usual advice is to be careful. Being careful does not scale and it does not survive a cache layer you forgot about.

What follows is the pre-flight I run instead. It takes about ninety seconds to set up and it makes a bad change expire on its own, so the worst outcome of a mistake is a ten minute wait rather than an FTP session at midnight. Everything runs against a site you own and already have shell access to.

Why bother, on a five minute job

Because the thing you are switching on is doing more work than the layer underneath it, so it is worth getting switched on properly and left on.

According to Patchstack's State of WordPress Security in 2026, 11,334 vulnerabilities were disclosed across the WordPress ecosystem during 2025, up 42% year on year, with 91% of them in plugins. Forty-six percent had no patch available at the moment of disclosure, and the weighted median time from disclosure to first exploitation was five hours.

The same report pentested common hosting defences. Internal WAFs, Cloudflare, Imunify360 and ModSecurity blocked 12% of attacks against known-exploited vulnerabilities, and 26% on a broader test. The best host in the set blocked 60.7%. Several blocked under 17%. One blocked nothing.

So the hardening layer matters, and the failure mode that actually destroys it is not an attacker. It is a site owner who broke something once, could not tell what, and turned the whole thing off.

Step 1: a restore point that takes two commands

Do this before anything else. It is cheap enough that there is no argument against it.

cd /var/www/example.com/public_html
STAMP=$(date +%F-%H%M%S)

# The rewrite rules, which is what a path change actually writes.
cp -a .htaccess "/root/restore/htaccess.$STAMP" 2>/dev/null || true

# Options only. Full DB dumps are slow enough that people skip them, and
# every setting you are about to change lives in wp_options.
wp db export "/root/restore/options.$STAMP.sql" --tables=$(wp db prefix --allow-root)options

wp db prefix matters there because the prefix is not always wp_, and a restore aimed at the wrong table name fails at exactly the moment you are least able to debug it.

Step 2: the dead man's switch

This is the part worth stealing. Schedule a job that reverts everything in ten minutes, then cancel it once you have confirmed the site is fine. If you lock yourself out, you do nothing at all and the site comes back.

cat >/root/restore/revert.sh <<'EOF'
#!/usr/bin/env bash
set -euo pipefail
SITE=/var/www/example.com/public_html
LATEST_HT=$(ls -1t /root/restore/htaccess.* 2>/dev/null | head -1)
[ -n "${LATEST_HT:-}" ] && cp -a "$LATEST_HT" "$SITE/.htaccess"
cd "$SITE"
# Substitute the slug of the plugin you are configuring.
wp plugin deactivate YOUR-PLUGIN-SLUG --allow-root || true
wp rewrite flush --hard --allow-root || true
logger -t wp-preflight "auto-revert fired"
EOF
chmod +x /root/restore/revert.sh

# Arm it. `at` is in most distro repos; install it if the command is missing.
echo "/root/restore/revert.sh" | at now + 10 minutes
atq            # note the job number

Now go and make your change. When the site is confirmed healthy:

atrm <job-number>     # disarm

If at is not available, a one-shot systemd timer does the same thing:

systemd-run --on-active=10min --unit=wp-preflight-revert /root/restore/revert.sh
# disarm with:
systemctl stop wp-preflight-revert.timer 2>/dev/null; systemctl reset-failed wp-preflight-revert.service

Ten minutes is the number I use because it is long enough to load a preset, purge caches and open the dashboard, and short enough that waiting it out is never worse than debugging under pressure. Re-arm it before each subsequent change rather than setting one long window.

Step 3: a watchdog in a second shell

Open another terminal before you touch anything and leave this running for the whole change window. It tells you the moment something stops answering, and it tells you which thing, which is the information the browser withholds while it sits on a spinner.

SITE="https://example.com"
LOGIN="/wp-login.php"          # change to your new path after the switch

while true; do
  printf '%s ' "$(date +%H:%M:%S)"
  for U in "/" "$LOGIN" "/wp-admin/" "/wp-json/"; do
    code=$(curl -s -o /dev/null -w '%{http_code}' --max-time 5 "$SITE$U")
    printf '%s=%s ' "$U" "$code"
  done
  echo
  sleep 5
done

Read the row, not a single number. Homepage 200 with the login path 404 is a path change that landed and a bookmark that did not, which is fine. Everything 200 except /wp-json/ is a REST route that did not get a matching rule, and it will show up later as saves failing silently. Homepage 500 is the rewrite file, and that is the case where you stop touching things and let the timer fire.

Step 4: WP-CLI is your out-of-band control plane

The reason a lockout feels catastrophic is that people assume the dashboard is the only way in. It is not, and knowing that in advance changes how much risk a path change actually carries.

WP-CLI does not go through HTTP. Rewrite rules are irrelevant to it. If the web-facing side of the site is unreachable, the command line still works completely.

wp plugin list --status=active --field=name         # what is on
wp plugin deactivate YOUR-PLUGIN-SLUG               # instant off, no dashboard needed
wp option get home; wp option get siteurl           # confirm nothing rewrote these
wp rewrite flush --hard                             # regenerate rules, no settings changed
wp user list --role=administrator --fields=user_login,user_email

The FTP-era equivalent, for hosts with no shell, is renaming the plugin directory. WordPress deactivates a plugin whose folder has vanished, and it does it without touching your database.

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

Both routes are worth testing once on a staging copy, because the first time you use a recovery procedure should not be the first time you read it.

Step 5: confirm the rules landed, not that you saved them

A saved setting and an applied rewrite rule are different objects. On Apache and LiteSpeed they usually coincide. On nginx they frequently do not, because plugins write .htaccess and nginx has never read .htaccess. The file gets written, the interface reports success, and the server carries on serving the old routes.

curl -sI "$SITE" | grep -i '^server:'
grep -c 'RewriteRule' .htaccess

# On nginx, the rules have to be in the server block instead:
sudo nginx -T 2>/dev/null | grep -n 'rewrite ' | head -20
sudo nginx -t && sudo systemctl reload nginx

nginx -t before every reload, without exception. A reload on a bad config is an outage, and an outage during a hardening window is the thing that convinces people hardening caused it.

Step 6: find and store the bypass route

Most plugins in this category generate a bypass parameter, a unique string that suspends path changes for a single request so you can reach the dashboard from outside your own configuration. It is generated at install time and it lives on a settings page, which is to say it lives behind the login form you may be about to move.

Look it up now, while you can still reach it, and put it in your password manager rather than a text file. Treat it as a credential: anyone holding it walks straight past your path security.

# Find where your plugin keeps its config, then read the relevant key.
wp option list --search='*YOURPREFIX*' --fields=option_name,option_value | head -40

If your plugin does not have one, its documented equivalents are the temporary pause from the plugins screen and the folder rename above. Know which you have before you need it.

The whole pre-flight

# 1. restore point
cp -a .htaccess /root/restore/htaccess.$(date +%F-%H%M%S)
wp db export /root/restore/options.$(date +%F-%H%M%S).sql --tables=$(wp db prefix)options

# 2. arm the dead man's switch
echo /root/restore/revert.sh | at now + 10 minutes

# 3. start the watchdog in a second shell
# 4. make exactly one change
# 5. confirm the row is green, then: atrm <job>

One change per window. That is the part people skip, and it is the part that turns a five second fix into an afternoon, because two simultaneous changes give you no way to attribute a failure to either of them.

None of this makes your configuration more secure. It makes being wrong cheap, and a hardening layer you are willing to touch is worth considerably more than a stronger one you are afraid to open.

What is in your pre-flight that is not in mine? I am particularly interested in anyone who has automated the cache purge into the same window, because that is the step I still do by hand and still occasionally forget.

Your Page Builder Did Not Break. One of Three Endpoints Stopped Resolving.

Calin V. — Wed, 16 Sep 2026 17:47:20 +0000

A page builder editor that hangs on the loading spinner, or saves and then reports failure with no error worth reading, is almost never a security problem. It is a routing problem with a security plugin's fingerprints on it, and the reason it is hard to fix from the dashboard is that the dashboard cannot tell you which request stopped resolving.

Three endpoints decide this. /wp-admin/, admin-ajax.php, and the REST API at /wp-json/. Every builder editor I have had to debug uses all three, in that order, and a security plugin that changes site paths can move any of them. What follows is how to find out which one moved without uninstalling anything.

All of it runs against a site you own.

Probe all three from outside the session

You do not need an authenticated cookie for the first pass. All three endpoints answer an anonymous request in a distinctive way, and the shape of the answer tells you whether the path still routes.

SITE="https://example.com"

# 1. wp-admin: an anonymous GET should 302 to the login form.
curl -s -o /dev/null -w '%{http_code} -> %{redirect_url}\n' "$SITE/wp-admin/"

# 2. admin-ajax.php: no action parameter, so WordPress answers "0" with a 400.
#    The status is the point. A 404 here means the path is gone.
curl -s -o /dev/null -w '%{http_code}\n' "$SITE/wp-admin/admin-ajax.php"

# 3. REST API index: an anonymous GET returns the route index as JSON.
curl -s -o /dev/null -w '%{http_code}\n' "$SITE/wp-json/"

Read it like this. A 302 from the first, a 400 from the second and a 200 from the third means all three default paths still resolve, and your editor problem is somewhere else. Cache, most likely. Skip to the cached-ajaxurl section.

Any 404 in that set is your answer. That endpoint has been changed and the server is not routing the new address to the old handler.

403 is a different animal and means a rule matched, not that the path moved. A firewall ruleset running at the rewrite layer will return 403 on a pattern match, and the editor's save payload can trip a rule written for SQL injection if it contains something that looks like one. If you get 403 on admin-ajax.php but 200 on /wp-json/, look at your ruleset before you look at your paths.

Tell a rewrite-layer 404 from a PHP 404

This distinction decides where you go looking, and it is measurable.

A rewrite-layer 404 is returned by Apache, LiteSpeed or nginx before PHP is invoked. A WordPress 404 is a full page load: bootstrap, database connection, template. The second one costs an order of magnitude more time.

# Compare a known static asset, a known WordPress 404, and the endpoint under test.
for U in "/favicon.ico" "/this-page-does-not-exist-9182" "/wp-admin/admin-ajax.php"; do
  printf '%-42s' "$U"
  curl -s -o /dev/null -w '%{http_code}  ttfb=%{time_starttransfer}s  size=%{size_download}\n' "$SITE$U"
done

A response that lands near the static file's TTFB with a tiny body never reached PHP, and the fix is in your rewrite rules. A response that lands near the WordPress 404's TTFB, with a full HTML page in the body, means PHP ran and WordPress itself did not recognise the request, which usually means a filter is rewriting the URL in output but no server rule was written to match it.

You can confirm from headers too. WordPress sets X-Robots-Tag and a Link header on real page loads that a server-level 404 will not carry.

curl -sI "$SITE/wp-admin/admin-ajax.php" | grep -Ei 'server|link|x-robots|x-powered-by'

The nginx trap

If your site runs nginx and the editor broke immediately after a path change, this is the cause more often than everything else combined.

Plugins in this category write rewrite rules into .htaccess. nginx does not read .htaccess. It never has, there is no module for it, and the file sits on disk being ignored while the plugin's interface reports that the rules were written. The plugin is not lying; it wrote the file. The server is not reading it.

# On the server. If this returns rules and you are on nginx, they are doing nothing.
grep -n -A20 'BEGIN' /var/www/example.com/public_html/.htaccess

# What is actually serving you:
curl -sI "$SITE" | grep -i '^server:'

The rules have to go into the server block and the service has to be reloaded. The generic shape, for a plugin that has moved a path and given you the mapping:

location ~* ^/your-new-ajax-path/?$ {
    rewrite ^ /wp-admin/admin-ajax.php last;
}

# and for a relocated REST namespace
location ~* ^/your-new-api-path/ {
    rewrite ^/your-new-api-path/(.*)$ /wp-json/$1 last;
}

sudo nginx -t && sudo systemctl reload nginx

Test the config before reloading, every time. nginx -t is the difference between a reload and an outage.

The stale ajaxurl nobody looks for

This is the failure that survives a correct configuration, and it is worth knowing because the probes above will all come back clean while the editor stays broken.

WordPress prints the AJAX endpoint into the page as a JavaScript variable, and builders read it from there rather than constructing it. If a full-page cache captured the HTML before the path change, or a JS concatenator inlined the old value into a bundle, the browser is sending editor requests to an address that no longer exists while the server is perfectly happy to route the new one.

# What the served HTML currently tells the browser the AJAX endpoint is:
curl -s "$SITE" | grep -oE '(var )?ajaxurl[^;]{0,120};' | head

# And what your builder's own localised config carries:
curl -s "$SITE" | grep -oE '"ajaxurl":"[^"]+"' | head

If either of those still shows the pre-change path, no amount of rewrite work will help. Purge in this order, because purging out of order just repopulates the layer you cleaned: CDN first, then server-level cache, then the WordPress cache plugin, then the browser. Any concatenated or minified JS bundles have to be regenerated, not just evicted.

While you are there, check the enqueued asset URLs too. A builder that loads its editor JS from a plugin directory whose name has been changed in output, without a matching server rule, produces a spinner that never resolves and zero errors in the PHP log, because the request never reached PHP.

curl -s "$SITE" | grep -oE 'src="[^"]+\.js[^"]*"' | head -20

Snapshot first, then bisect

Take the restore point before you change anything else. It is two commands and it converts every subsequent step from a risk into an experiment.

cd /var/www/example.com/public_html
cp .htaccess ".htaccess.$(date +%F-%H%M)"
wp db export "pre-path-change-$(date +%F-%H%M).sql" --add-drop-table

Then revert one endpoint at a time, in this order, testing a real save in the editor between each step:

The AJAX endpoint. Most builder failures are here, because the editor talks to it continuously and the URL is baked into output rather than resolved at request time.
The REST API path. Saving is what breaks, and it often breaks silently, which makes this the second most likely and the most annoying to diagnose.
The admin path. On hosts that restrict what can be done with the admin directory, this one fails in ways that look like a permissions problem. Find where your plugin keeps that configuration rather than guessing at option names:

# Substitute your plugin's own option prefix for PREFIX. `wp plugin list` will remind you of the slug.
wp plugin list --status=active --field=name
wp option list --search='*PREFIX*' --fields=option_name,option_value | head -40

Between each revert, log out and back in through your current login path. Session cookies are issued against the paths that were in force at the time, and stale cookies produce save failures that look exactly like a routing problem but are not one. Then resave permalinks, which regenerates rewrite rules without changing any setting.

The rule that prevents all of this

Anonymous traffic never touches these three endpoints. Automated scanning goes after the front end: plugin and theme directories, readme files, the login form, version strings in your page source. Changing those breaks the reconnaissance step of an automated attack. Changing admin-ajax.php breaks your editor and adds close to nothing, because nothing hostile was looking there.

So the configuration that costs you nothing and buys you most of the benefit is to change everything an unauthenticated request can see and leave the three endpoints your own tooling depends on exactly where they are.

That is not a compromise position. According to Patchstack's State of WordPress Security in 2026, 91% of the 11,334 vulnerabilities disclosed across the WordPress ecosystem in 2025 were in plugins, 46% of them had no patch available at the moment of disclosure, and the weighted median time from disclosure to first exploitation was five hours. Reducing what is reachable is the layer that does anything at all inside a five-hour window. A custom AJAX path is not part of that layer, and the same report's pentest of hosting defences, where internal WAFs, Cloudflare, Imunify360 and ModSecurity blocked 12% of attacks against known-exploited vulnerabilities and 26% on a broader test, is a reasonable prior for how much the layer underneath is contributing.

A control that gets deactivated in July because it broke an editor is protecting nothing in August. The setting you leave alone is part of the security configuration.

What is the endpoint failure that cost you the most time before you found it? I am after the one where every probe came back clean and the answer turned out to be somewhere else entirely.

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.