Read a sample first
Three things from the book, free, so you can judge the voice and the depth before paying. The quick start below is what most readers act on first. Chapter 1 is free in full. And one section from a locked chapter, chosen because it is the part of the book people write to me about.
The quick start
From the welcome chapter. Sixteen things, in priority order.
If you want the 80/20 version before getting into the full book, this is it. The most useful things to do on any WordPress site, in rough priority order.
Do these immediately on any new or existing site:
- Keep WordPress core, plugins, and themes updated. Out of date plugins cause more WordPress compromises than everything else put together.
- Install Wordfence (free). Firewall, malware scanning, login security, and 2FA in one plugin.
- Change the default
/wp-login.phplogin URL using a plugin like WPS Hide Login. - Limit login attempts and enforce 2FA on all admin accounts. Use passkeys where your plugin supports them, since they can't be phished.
- Disable the built in file editor in
wp-config.php:define( 'DISALLOW_FILE_EDIT', true ); - Install an SSL certificate and force HTTPS. Let's Encrypt is free.
- Set up automated off site backups. UpdraftPlus (free tier) to Google Drive or S3 covers the basics.
- Set up uptime monitoring. UptimeRobot (free tier) takes two minutes.
- Install WP Mail SMTP so your site sends email reliably via a proper mail provider.
- Remove any plugins and themes you're not actively using.
- Check whether anything is driving your site through Application Passwords or an AI agent, and turn them off if nothing is using them.
If you manage your own server, also do these:
- Disable root SSH login and enforce SSH key authentication.
- Configure a firewall (UFW) and install Fail2Ban.
- Run a supported PHP version (8.3 or 8.4 as of 2026, with 8.4 the better target).
- Block PHP execution in the uploads directory.
- Set file permissions correctly:
755directories,644files,440forwp-config.php.
That covers the majority of common attack vectors on a WordPress site. The rest of the book gets into why each one matters, how to do it properly, and what to do once the basics are in place.
Chapter 1 is free, all of it
Server and hosting: managed versus self-managed, what a good host actually does for you, PHP and operating system choices, the server basics, and the hosting red flags that make everything after it harder. About 1,800 words, no signup.
Read Chapter 1From Chapter 8: the other files that load themselves
A locked chapter. This is the section on why "self-healing" malware keeps coming back, and where to look.
mu-plugins is the auto loading directory people have at least heard of. It isn't the only one, and the others are where a cleanup usually goes wrong.
WordPress supports a set of files called drop-ins. They live directly in wp-content/, not in a subfolder, and WordPress loads them automatically if they exist. They don't appear in the plugins list as normal plugins, they can't be deactivated from the admin, and reinstalling WordPress core doesn't remove them, because core doesn't own wp-content. The two that matter most for our purposes:
wp-content/db.phploads on every request that touches the database, which in practice means every request. It needs no constant set and no configuration. Dropping a file at that path is enough.wp-content/advanced-cache.phploads whenWP_CACHEis defined as true inwp-config.php. Note the ordering: an attacker who can write towp-config.phpcan set that constant themselves, so "I don't use a caching plugin" is not a reason for the file to be absent.
Legitimate software uses both. Most caching and database tools install one or the other, which is exactly what makes them comfortable places to hide. A db.php on a site running a caching plugin looks entirely ordinary at a glance.
Then there's the one that sits below WordPress altogether.
A .user.ini file lets you override PHP settings per directory when PHP runs under CGI or FastCGI, which covers most modern WordPress hosting including PHP-FPM. It's the FastCGI equivalent of putting PHP directives in .htaccess. Among the settings it accepts is auto_prepend_file, which names a PHP file to execute before the requested script runs.
Take a moment with the implication. If a .user.ini in your web root sets auto_prepend_file to a file the attacker controls, that file runs first, on every single PHP request. Before index.php. Before WordPress loads. Before any security plugin you've installed has an opinion about anything. You can replace WordPress core, replace every plugin, replace the theme, and the site is still compromised, because none of those things are what's executing the malicious code.
This is the mechanism behind the infections people describe as self healing. Files get deleted and reappear within a second, and it looks supernatural, when in fact something is running before WordPress on every request and simply writing them back. The rewriting isn't the infection. It's a symptom of the thing that loads first.
So when you audit a site, check all of it:
# Drop-ins sitting directly in wp-content
ls -la wp-content/*.php
# Must-use plugins
ls -la wp-content/mu-plugins/
# .user.ini anywhere in the tree, including hidden ones
find . -name ".user.ini"
# Anything setting a prepend directive
grep -rn "auto_prepend_file" . --include="*.ini" --include=".htaccess"
On a normal WordPress install, wp-content/*.php returns either nothing or a small number of files you can account for, and find . -name ".user.ini" usually returns nothing at all. Anything you can't explain, investigate before you conclude the site is clean.
One practical note. PHP caches .user.ini contents for five minutes by default, controlled by user_ini.cache_ttl. If you remove one during a cleanup, the directive can stay active until that cache expires or PHP-FPM is restarted. Don't take "I deleted it and it's still happening" as proof of a second infection until you've restarted PHP.
Chapter 8 continues with the plugin ownership-transfer risk, nulled plugins, audit logging and vulnerability monitoring.
What's inside
14 chapters, from the server up. Chapter 1 is free to read in full. The rest unlock with one payment.
-
Server & Hosting Environment Free
Managed or self-managed, what a good host actually does for you, PHP and OS choices, and the hosting red flags that make everything else harder.
-
WordPress Core Hardening Locked
wp-config.php above the webroot and unwritable, the files nobody should be able to reach, no PHP in uploads, the login lockdown, and replacing WP-Cron.
-
User & Authentication Security Locked
Roles, passwords that survive a leak, 2FA and passkeys, closing XML-RPC and the REST user endpoints, and keeping application passwords under control.
-
File & Directory Permissions Locked
The owner, group and world model in plain English, the right numbers for every part of a WordPress install, and the audit that finds world-writable files.
-
Database Security Locked
Least-privilege database users, host restrictions, credential hygiene, and the triggers trick that reinfects a site from inside the database.
-
SSL, HTTPS & Network Security Locked
Let's Encrypt, HSTS without locking yourself out, every security header explained, and an honest account of why a strict CSP on WordPress is hard.
-
Firewall & Intrusion Prevention Locked
Cloudflare's free tier configured properly, locking the origin so attackers can't go round it, Wordfence, Fail2Ban, and bot management.
-
Plugin & Theme Hygiene Locked
Vetting plugins, the tiered update policy, ownership-transfer risk, and the auto-loading files (mu-plugins, drop-ins, .user.ini) behind "self-healing" malware.
-
Performance & Caching Locked
Page and object caching done safely, Redis, CDN setup, image handling, and why a slow site is a security problem as well as a sales one.
-
Monitoring, Logging & Alerting Locked
Uptime checks, the alerts worth having and the ones that cause fatigue, log analysis one-liners, and file integrity monitoring.
-
Backups & Disaster Recovery Locked
Backups that actually restore, retention that survives a slow-burn compromise, and the six-step response that stops a cleanup turning into whack-a-mole.
-
Maintenance Workflows Locked
Staging, the weekly, monthly and quarterly routine, a safe update workflow, cron-event auditing, and the 46-point security review checklist.
-
WordPress for Agencies & Freelancers Locked
Per-client isolation, the one-account-many-sites trap, the handover document, communicating an incident, and packaging maintenance as a retainer.
-
AI Agents & the MCP Attack Surface Locked
What WordPress 7.0's agent stack exposes, why an ability cannot tell who is calling it, where provider keys end up, and how to switch the whole thing off.
One payment, permanent access, every future update, PDF included.