Advanced WordPress security hardening in 2026

A WordPress security plugin on a writable origin is not hardening. Hardening in 2026 is identity, a read-only runtime, an edge that can drop a payload before PHP starts, and logs the origin cannot delete.

WordPress 7.1 on PHP 8.4 is a maintained application. It is also the thing attackers scan first, because the plugin directory, xmlrpc.php, and wp-login.php are predictable. The incidents we still clean up are not “WordPress is insecure”. They are a public admin, a Friday dashboard update, and a host that lets PHP write to itself.

This guide is the operating version. Passkeys, immutable images, WAF virtual patching, CSP nonces, composer audits, off-box logs. The WordPress security audit is the commercial surface when you want that stack inspected rather than described.

#Identity first: passkeys and wp-admin off the public internet

The login form is still the cheapest attack. Credential stuffing does not need a zero-day. It needs wp-login.php on the open internet and an administrator who reused a password from a breach dump.

Passkeys (WebAuthn) bind the ceremony to the device and to the origin. A lookalike domain does not complete it. That is why we force passkeys for every account that can install plugins or edit PHP in the theme editor (which should also be off). Application passwords for CI stay in the secret store, not in a staff password manager shared with marketing.

Do not leave password login as the “just in case” fallback on the public URL. The fallback is how phishing still works. Break-glass is a hardware key in a safe, or recovery through the identity provider, on a path that is not wp-login.php.

wp-admin does not belong on the public internet. Cloudflare Access, a Tailscale funnel, or the identity-aware proxy your company already uses for internal tools. Anonymous GET of the storefront stays cached. /wp-admin and wp-login.php return 403 or an SSO challenge. xmlrpc.php is off unless Jetpack or a mobile app truly needs it, and then it is allow-listed by method and by IP, not left as a pingback cannon.

We still see shops that “hid” wp-admin by renaming the login slug. That is not identity. Crawlers find the new slug in a day. Hide the surface behind identity, or do not bother.

REST is not “safer than xmlrpc” by default. /wp-json/wp/v2/users enumerates logins on many default installs. Application passwords for a headless front should be scoped and rotated. The users endpoint is GET for a reason on public blogs. On a shop it is a gift. Disable it or require auth. The same for ?author=1 redirects that leak admin as the nicename.

Rate-limiting login in PHP is how you DDoS yourself. The WAF or Access does that work. If you must keep a public login for subscribers (a membership site), administrators still go through Access on a different hostname. One wp-login.php for everyone is how a stuffing run locks the editor out of their own site.

#Immutable runtime: the disk that refuses a shell

Dashboard updates are a security decision. They look like convenience. They are a write to production by whoever has an admin cookie.

Treat the PHP tree as read-only. WordPress runs from an image (container, or a rsync of a build artefact). wp-content/plugins and wp-content/themes are in that image. The only writable volume is uploads, and that volume does not execute PHP. If a plugin RCE tries to drop wp-content/uploads/cache.php, the write fails or the file is not in the executable path.

Updates then happen in git:

1. Dependabot or a scheduled composer bump opens a PR.
2. CI runs phpstan, a smoke test, and a lockfile CVE scan.
3. The image is built and deployed. The previous image is still there to roll back.

The live server is never “edited”. That also kills the class of malware that persists by writing to wp-config.php or to a must-use plugin the dashboard never lists.

Database user: SELECT, INSERT, UPDATE, DELETE on the site schema. No DROP, no FILE, no GRANT. TLS to MySQL. Table prefix is not a control. It is trivia.

Object cache (Redis) holds sessions and transients. Treat it as a store of secrets. Network isolation, AUTH, no public port. A “flush all” from a compromised admin is an availability incident. Separate the cache for sessions from the cache for HTML fragments if you can. We have seen a plugin write a reset-password token into a shared Redis and another site on the same host read it. That is a hosting layout bug, not a WordPress bug, and it still lands in your incident channel.

wp-config.php keys (AUTH_KEY and friends) rotate when you suspect cookie theft, and the old sessions die. Putting those keys in the environment, not in the image, means a leaked repo is not a leaked login. The image still needs a way to boot. Use the platform secret store. Do not commit a .env to the same git that the front-end agency can clone.

#WAF and virtual patching

The WAF sits in front of origin. It sees the HTTP request before PHP boots. That is the only reason it is worth the money.

What it is for:

• Known exploit paths: /wp-login.php floods, xmlrpc multicall, REST routes that should not be anonymous.
• A virtual patch the day a WooCommerce or Elementor CVE is public, while you rebuild the image. Hours, not the weekend.
• Rate limits that the application would otherwise implement badly in PHP.

What it is not for: replacing input validation, or being the only copy of your access log.

Managed WordPress hosts often sell “we have a WAF”. Ask whether you can add a rule the same day, and whether the rule hits before PHP. If the answer is a ticket queue, it is not virtual patching.

#Wordfence on origin versus a WAF at the edge

This is the operating choice we keep repeating, and it is the one that splits a cheap “security plugin” from a stack that still answers after a CVE Friday.

Wordfence, Sucuri plugin, iThemes, they run inside PHP. They can scan files, they can throttle wp-login, they can email you. They start after the request has already reached origin. A payload that exploits the PHP worker before the plugin’s init hook is not something they see in time. They also need a writable filesystem for their own data, which fights the read-only runtime.

Cloudflare WAF (or Fastly, or the WAF in front of your VPS) runs on the cache node. Anonymous GET can stay a cache hit. A POST that matches a CVE signature never reaches PHP. Virtual patching is a rule push, not a plugin update. The origin image stays read-only.

Rules we use:

• Login and xmlrpc only from Access, or blocked. Storefront POST (checkout, account) goes through WAF with a managed WordPress ruleset plus a custom skip for the payment webhook paths you actually own (Stripe, Klarna). Skipping /wp-admin/admin-ajax.php wholesale is how people break their own WAF.
• Wordfence, if it stays at all, is a scanner in CI or on a staging clone, not a runtime firewall on production. Two firewalls that both think they own rate limits will lock out real customers and still miss the CVE.
• File integrity: compare the deployed image to git, not a plugin walking wp-content on every cron. Cron on origin is another PHP process you did not need.

A UK or US shop we rebuilt in 2025 had Wordfence “in high sensitivity”, Cloudflare “I’m under attack” on the same URL, and a marketing pixel that POST’d to admin-ajax. Checkout failed for a day. The CVE they were scared of was patched at the edge in one rule. The plugin fight was the outage.

Virtual patching has a shelf life. The WAF rule is the weekend. The image rebuild is the week. If the rule is still the only fix six months later, you do not have a pipeline, you have a sticky note. We treat an open virtual patch as a ticket with an owner, not as a badge.

Skip lists are where WAFs go to die. /wp-admin/admin-ajax.php, /?wc-ajax=, Stripe webhooks, Apple Pay domain verify. Each skip is a written exception with a reason. A skip for “the cookie banner broke” that also opens admin-ajax to the world is how a cheap plugin becomes an origin RCE again.

#CSP nonces, not a comment in .htaccess

Content-Security-Policy is the browser refusing to run a script you did not send. XSS in a plugin still happens. CSP is what stops that script from calling out.

A policy that works on a WordPress theme, in practice:

• default-src 'self'
• script-src 'self' 'nonce-…' plus the two or three payment origins you can name
• style-src 'self' 'unsafe-inline' until you have hashed the theme (unsafe-inline on style is a compromise; do not copy it onto script)
• frame-ancestors 'none' unless you truly embed the site
• object-src 'none'
• base-uri 'self'

The nonce has to change per response. A static nonce in wp_head is theatre. HTMLRewriter at the edge, or a PHP mu-plugin that prints the header and the matching attributes, both work. The plugin directory is full of “add CSP” plugins that emit 'unsafe-inline' on script. That policy does not stop XSS. It documents that you tried.

Report-Only first. Look at the reports for a week. Then enforce. Stripe, Tag Manager, and the consent platform will be in the report. Each one is a decision: allow by origin, or take it off the first party page.

CSP is not a substitute for esc_html and nonces on forms. It is the last fence.

#Supply chain: composer, the plugin directory, and Friday updates

Most WordPress compromises we still see start as a plugin, not as core. Core has a release process. A plugin with 200,000 installs can ship a phone-home in a minor.

What we do:

• Plugins you depend on live in composer (wpackagist or a private mirror) so the lockfile is the bill of materials. “Install from wp-admin” is off on production.
• CI fails the PR if composer audit or the npm audit on the theme toolchain reports a known CVE above the bar you set. The bar is not “critical only”. A forgotten XSS in a form plugin is enough.
• New plugins get a read of eval, file_get_contents of remote URLs, and admin-post handlers before they enter the mirror. That is an hour, not a security theatre certificate.
• Auto-updates on production are off. Auto-updates on a staging clone that promotes through the same pipeline are fine.

The NIS2 and DORA readiness pillar is where the EU operator duties live. This section is the engineering that makes those duties possible: you can name what is running, and you can rebuild it.

#Logs that survive the incident

If the only copy of auth.log and the PHP error log is on the host that just got a shell, you will not have an incident timeline. You will have a rebuilt server and a guess.

Stream:

• nginx or Cloudflare request logs (WAF action, path, country, ray id)
• PHP-FPM errors and slow log
• WordPress authenticate failures and user_register / set_role
• Deploy events from CI (who shipped which image)

to a bucket or a SIEM the origin role cannot delete. Retention you can actually search: 90 days hot is enough for a shop; regulated readers go longer because their counsel said so, not because a plugin offered “log retention”.

Alert on: spike of 401 on wp-login (if it is still public, that is already the bug), new administrator, plugin file hash drift against git, WAF block rate stepping up on a REST route.

Do not buy “AI anomaly detection” as the first control. The first control is “we have the logs” and “someone reads the admin-create events on Monday”.

#What we actually change in the first week

A hardening engagement is not a 25-row spreadsheet. It is a short sequence you can finish.

1. Screenshot the current plugin list and the last dashboard updates. That is the crime scene if something is already wrong.
2. Put Access in front of wp-admin. Force passkeys for administrators. Turn off xmlrpc if unused.
3. Stop plugin installs on production. Open the composer path even if the first commit is just pinning what is already there.
4. Add a WAF managed ruleset and one virtual patch you can name (the last CVE in your plugin list).
5. Ship CSP in Report-Only. Read the report.
6. Ship logs off-box. Confirm you can grep a failed login from yesterday without SSH to origin.

Then the image becomes read-only. That step last, because it breaks “edit in wp-admin” workflows that nobody documented. Document them first or you will roll back the read-only flag on Saturday.

The editor who pastes into a reusable block, the marketer who installs “one small” popup, the freelancer who has admin because “they need to upload a PDF”: those three accounts are the remaining write path. Two of them should be editor or a custom role that cannot install plugins. The PDF goes to uploads, which cannot execute PHP. If they need a new plugin, that is a PR, not a Friday.

Backups are not hardening, but they are how you leave an incident. Off-site, versioned, restore tested on a clone that is not production. A backup that only lives on the same VPS is a second copy of the same disk. We restore a staging clone before we call the work done, because a backup you have never restored is a file, not a plan.

#Audit and further reading

The WordPress security audit is identity, runtime, edge, and logs on your actual host, not a generic checklist. We open wp-admin exposure and the plugin lockfile first. Lighthouse-style scores are not a security signal.

EU operator duties (logging, incident clocks, named contacts) sit in NIS2 and DORA readiness. Architecture that shrinks PHP on the public origin is in the headless architecture guide. Headless is not a security control by itself. It is a smaller PHP surface if the front is static and wp-admin is private.

#Conclusion

WordPress core is not the weak part. The weak part is a public login, a writable disk, a security plugin that runs after PHP has started, and logs that die with the host. Passkeys, an identity-aware wp-admin, a read-only image, a WAF that can virtual-patch, CSP with real nonces, a lockfile, and off-box logs. That is the list. A plugin page that says “protected” is not on it.

Write with the URL, the plugin list, and whether wp-admin is public, if you want that inspected. The security audit is the commercial surface.

HIPAA, PCI, ISO 27001: none of them are a plugin. PCI means card data never in WordPress. ISO is the operator process around what this guide already lists. If a vendor sells “SOC2 WordPress”, ask for the report on their hosting, not a badge in the footer.