Security advisorywp2shell: WordPress core vulnerability. Updated August 4, 2026.

Read the advisory

WordPress Security Hardening Guide 2026

A practical WordPress hardening guide: updates, logins, wp-config, permissions, plugins, firewall, scanning, backups, and a simple rollout order.

Topics Hardening & checklists Beginner guides

Lars Koudal

Updated Published

Hardening WordPress means closing the usual doors before bots find them. Not theater, and not brochure stats. Just configuration and habits that make your site a worse target.

WordPress Security Hardening Guide

What you are actually hardening

Think in layers:

  1. WordPress core and config (wp-config.php, updates, file edit locks)
  2. Plugins and themes (fewer, updated, trusted)
  3. People and logins (passwords, 2FA, roles)
  4. Server / host edge (HTTPS, firewall, PHP version)
  5. Detection and recovery (scans, events, backups)

Most compromises still start with outdated plugins or weak admin access. Start there even if you never touch Apache configs.

1. Keep software current

  • Update WordPress core promptly, especially security releases
  • Update plugins and themes on a schedule
  • Delete unused plugins and themes (deactivated is not deleted)
  • Keep PHP on a supported version your host recommends

Use staging for fragile sites. Auto-update trusted plugins when you can.

2. Harden wp-config.php

Generate fresh WordPress salts/keys after a compromise, or when you inherit a site.

On production:

define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );

Stop theme/plugin file editing from wp-admin:

define( 'DISALLOW_FILE_EDIT', true );

Only use DISALLOW_FILE_MODS if you intentionally manage updates outside wp-admin. It blocks plugin/theme installs and updates from the dashboard.

A custom table prefix helps a little against dumb automated scripts. It is not a substitute for updates and strong logins. Changing prefix on a live site needs care; do it on new installs when you can.

3. File permissions (sane defaults)

Exact values depend on the host, but a common baseline is:

  • Directories: 755
  • Files: 644
  • wp-config.php: tighter when possible (600 or 640)

Avoid 777. If the site breaks after tightening permissions, ask the host what their WordPress stack expects instead of opening everything up.

Core Scanner helps spot unexpected changes to WordPress core files after hardening.

4. Lock down logins

Strong password guidance

  • Unique long passwords in a password manager
  • No shared “team admin” account
  • Few administrators; everyone else gets the lowest role that works
  • Two-factor authentication for admins
  • Limit failed logins and consider renaming the login URL via login protection

Rename alone is not enough. Combine it with rate limiting and 2FA.

5. Plugins and themes

  • Prefer WordPress.org or known commercial vendors
  • Check last update date before install
  • Never use nulled “premium” packages
  • Remove abandoned plugins you cannot replace soon

Scan installed software for known issues with the vulnerability scanner (included free). Deeper plugin hygiene: plugin security risks.

6. HTTPS, host, and edge protection

  • Force HTTPS site-wide
  • Pick a host with working backups and support
  • Put a cloud firewall in front of WordPress to cut exploit and brute-force noise
  • Keep the server/PHP stack updated (your host usually owns this on managed plans)

Server deep-dives (Apache hardening, custom TLS ciphers, DB privilege surgery) help when you control the VPS. On shared or managed WordPress hosting, spend your time on updates, logins, firewall, and backups first.

Security headers (nice, not magic)

If your host or a security plugin can set headers, useful ones include:

  • Strict-Transport-Security (HSTS) after HTTPS is solid
  • X-Content-Type-Options: nosniff
  • Referrer-Policy with a sensible default
  • Content-Security-Policy only if you can maintain it (easy to break the site)

Headers help browsers behave better. They do not replace patching plugins.

Database habits worth doing

  • Strong unique DB password (host panel usually sets this)
  • Do not share the DB user across unrelated apps
  • Avoid granting exotic privileges the site does not need
  • After a compromise, assume the DB may contain junk users, options, or injected content; restore or clean carefully

7. Detect problems early

Hardening without monitoring still fails quietly.

  • Run malware scans on a schedule
  • Watch the events log for odd logins, blocks, and changes
  • Turn on alerts (email/webhooks) for things that matter
  • Check Search Console if traffic or warnings look wrong
  • Re-run security tests after bigger changes so regressions do not sit unnoticed

Scheduled scans matter because most site owners do not open the dashboard every day. Set the schedule, then check failures.

8. Backups you can restore

Hardening reduces risk. Backups limit damage.

  • Automatic backups
  • Off-site copies
  • Retention long enough to go back before an infection started
  • One restore test so you know the process

Details: backup plan after an attack.

Store backup credentials outside the site. If malware can read your wp-admin, you do not want the only restore path living in the same compromise.

A practical rollout order

Day 1

  1. Backups confirmed
  2. Update everything; delete unused plugins/themes
  3. Fix admin accounts, passwords, 2FA
  4. Enable login protection + firewall if you have Pro

This week

  1. DISALLOW_FILE_EDIT, debug off on production
  2. Permission check
  3. Vulnerability + malware scan; fix what you find
  4. Security tests / hardening checklist in Security Ninja

Ongoing

  1. Monthly update + admin review
  2. Scheduled scans and backup success checks

Security Ninja covers security tests, vulnerability checks, core integrity, events, and (on Pro) firewall, malware scanning, scheduled scans, and 2FA. Start free on WordPress.org, or get Pro when you want the full stack. The install wizard turns on sensible defaults so you are not guessing which toggles matter first.

Common hardening questions

Do I need to rename the wp-content folder?
Usually no. It breaks things, and bots already probe plenty of other paths. Focus on updates, logins, and scanning.

Should I disable XML-RPC?
Only if nothing you use needs it (some mobile apps, Jetpack-related flows, remote tools). Blindly disabling it can break integrations. Prefer firewall rate limits and strong auth.

Is renaming the login URL enough?
No. It reduces noise. Pair it with failed-login limits and 2FA.

Can I harden once and forget it?
No. New plugin CVEs show up constantly. Hardening is a baseline plus a maintenance habit.

If the site is already compromised

Do not “harden” over active malware and call it done. Clean or restore first, then harden so they do not walk back in. Guide: WordPress site hacked. Need help? Hire cleanup or a review.

Found this useful? Share it.