WordPress security hardening: 10 mandatory steps

WordPress security hardening is not a single action but a continuous process. For Hanse Studio B2B clients it is built into the 800 PLN/month retainer. In 2026 the threat landscape has shifted: plugin CVE dethroned brute force as the top attack vector, supply chain compromises hit popular plugins (UpdraftPlus, Elementor, LiteSpeed Cache), and XML-RPC abuse is back as a DDoS amplification tool. This runbook covers the 10 steps we apply on every client site before go-live and maintain weekly inside our retainers.

A Lighthouse 99/100 score and the full WordPress performance runbook without this hardening is like parking a new car without locking the doors. Performance and security are two sides of the same infrastructure, which we also describe in the context of our no-Elementor stack.

WordPress security hardening: 10 mandatory steps in 2026

The list below is not exhaustive, but according to the Patchstack Threat Report 2025 these 10 steps stop 95 percent of real WordPress incidents. Each takes between 15 minutes and 2 hours one time plus ongoing monitoring. Skipping even one disproportionately increases incident risk.

WordPress threat landscape in 2026

According to the Patchstack Vulnerability Database for 2024 and 2025, four incident categories dominate. The first is plugin CVE: a vulnerability published in a popular plugin before clients have time to update. Classic example: Elementor Pro hit four critical CVEs in 2024 and 2025, including an Account Takeover (CVSS 9.9) in August 2024, affecting hundreds of thousands of sites. LiteSpeed Cache similarly: a critical Privilege Escalation in August 2024 (CVSS 8.8), requiring an update plus API key rotation.

The second category is brute force and credential stuffing, attacks against wp-login and wp-admin. Brute force in 2026 is still common but mostly automated (bots with 100k+ IPs), so the fix is automated too (rate limiting plus 2FA). The third: theme and child theme vulnerabilities. Fewer published CVEs because the ecosystem is smaller, but a custom child theme with bad code (SQL injection in a custom shortcode, XSS in an admin notice) is a real risk.

The fourth is supply chain: droppers landed in popular plugins after an author account on the WP.org repo is taken over. Real cases in 2024 with Social Warfare and AccessPress Themes (3000+ themes infected). Plus XML-RPC abuse: the legacy API endpoint used for DDoS amplification and pingback brute force. Most sites do not use XML-RPC in 2026, so the fix is to disable it entirely.

Steps 1 to 3: update hygiene

Update hygiene is defense number one against plugin CVE and theme vulnerabilities. WP core minor auto-update (security patches) must always be on, configured in wp-config.php. Major updates (6.4 to 6.5) stay manual after a staging test, because they occasionally break plugins.

• Step 1: WP core minor auto-update enabled, major manual after a staging test
• Step 2: Plugin manual review before any major update, read the changelog, especially security advisories
• Step 3: Monthly wp plugin status audit, drop unused plugins, flag abandoned ones (no update for 12+ months means candidate for replacement)

Hanse Studio process: every retainer client gets a monthly audit via wp-cli. The command wp plugin status lists installed plus version plus update available. We cross-reference with the Patchstack Database (free public lookup) for every plugin with a CVE in the last 12 months. Output: a PDF report with three lists: “update now”, “update after staging test”, “consider replacement” (for plugins patched too late).

Abandoned plugins are a red flag. Any plugin without an update for 12+ months suggests the author lost interest or dropped the project. These plugins will not get a patch when a CVE arrives. Procedure: find an actively maintained alternative or fold the feature into custom code inside the child theme. Typical pattern: 5 to 7 abandoned plugins per legacy client site.

Steps 4 and 5: users and passwords

Brute force and credential stuffing remain frequent incident sources, even though automated. Default admin username plus a weak password is a classic vector. Procedure: change the admin username (via wp user create new_admin plus role assignment plus wp user delete admin --reassign=new_admin) and enforce a strong password policy for every user with edit_posts capability or higher.

• Step 4: Strong password mandatory (12+ characters, mix of digits, letters, special characters), enforced via a Password Policy Manager plugin
• Step 5: 2FA mandatory for all users from contributor role upwards, using WP 2FA plugin (free, Wordfence-owned) or Authy

2FA is the single biggest leverage in preventing credential stuffing. Without it, a brute force pass through 10 million leaked passwords (haveibeenpwned) has a real chance of hitting a user who reused a password elsewhere. With 2FA via TOTP (Authy, Google Authenticator), even if the password leaks, the attacker still needs physical phone access.

Disable XML-RPC unless you actually need it. A standard filter in the child theme functions.php shuts the endpoint down. Plus block pingback (another XML-RPC vector) by removing the relevant action hook and XML-RPC method. If the client uses Jetpack, XML-RPC stays (Jetpack depends on it), but it must be rate limited via a plugin.

Role audit: does every admin user really need admin? Most clients have 1 to 2 real admins (the developer plus the client owner), the rest are editors or authors. The command wp user list --role=administrator reveals everyone. Downgrade content creators to editor and the attack surface shrinks (editor cannot install plugins, the biggest risk).

Steps 6 and 7: file permissions and wp-config

File system security is often skipped but critical. wp-config.php holds DB credentials and salt keys, so access to that file equals site takeover. Permissions: 600 (read/write only for the owner), never 644.

• Step 6: wp-config.php chmod 600, .htaccess deny access to wp-config.php (extra layer)
• Step 7: disable the plugin/theme editor in wp-admin via a wp-config.php flag, regenerate salt keys every 6 months (generator at api.wordpress.org/secret-key)

Disabling PHP execution inside the uploads directory is critical to prevent malicious PHP upload through a plugin vulnerability. A standard rule in .htaccess inside wp-content/uploads/ blocks every file ending in php / phtml / phar.

In addition you can fully block plugin install and update from wp-admin (forcing deployment via SSH/wp-cli). For clients with dedicated DevOps (Hanse Studio retainers) this is a natural fit. For clients who want to install plugins themselves we stop at disabling the file editor only.

Step 8: Web Application Firewall (WAF)

A WAF blocks known attack patterns at the HTTP request layer before they reach PHP. Two main options for SMBs: Cloudflare WAF (managed rules on the Pro plan, 20 EUR/month) or the Wordfence plugin (free tier is fine for most B2B).

• Cloudflare WAF Managed Rules (Pro plan): blocks OWASP Top 10 attacks, rate limits login attempts, bot protection
• Cloudflare Super Bot Fight Mode: blocks known bad bots (credential stuffing networks)
• Wordfence plugin (free): plugin-level WAF, fine for sites without Cloudflare
• Geofencing: if the client is regional (e.g. PL B2B), block traffic from high-risk geographies (Russia, North Korea, etc.)

Hanse Studio default: Cloudflare Pro at 20 EUR/month for clients with budget (a property developer client, our own studio site, a drone videography client). Clients on a tighter budget get Wordfence free plus Cloudflare Free (basic DDoS protection without managed WAF rules, but still better than nothing). For Cloudflare setup details see our Cloudflare plus WordPress setup.

Step 9: backup and recovery

Backup is not security per se but a recovery layer when everything else fails. Rule: 3-2-1 backup (3 copies, 2 different media, 1 offsite). Plugin: UpdraftPlus Premium (49 USD/year), BackWPup (free for basic, Pro 69 EUR/year) or WP Time Capsule. Offsite storage: Backblaze B2 (cheap, S3-compatible) or Hetzner Storage Box for clients already on Hetzner.

• Daily DB backup, 30 day retention
• Weekly full backup (files plus DB), 90 day retention
• Offsite storage: Backblaze B2 (1 USD/TB/month) or Hetzner Storage Box (3 EUR/100 GB)
• Test restore quarterly: into a staging environment, do not wait for an incident
• Pre-update backup: every major plugin/theme update triggers a backup snapshot

Test restore is the step most often skipped. A backup that was never restored is a backup that may not work during an incident. Procedure: once per quarter copy the backup to staging, run a full restore, verify wp-admin login plus front-end render plus key forms work. Time: 1 to 2 hours per client, but it eliminates 90 percent of the “backup unreadable” risk during a real incident.

Step 10: monitoring and intrusion detection

Monitoring and intrusion detection are the last layer: instead of preventing (steps 1 to 9), detect an incident early. Without monitoring, a typical client only finds out about a breach when the site starts throwing errors, or when their client notices tampered products.

• Wordfence file changes monitor: email alert when plugin/theme/core files change outside a scheduled update
• Login attempt log: Wordfence or WP Activity Log, 30 day retention
• Plugin integrity check: a cron job comparing plugin file checksums against the WP.org reference
• Uptime monitor: UptimeRobot free (50 monitors), alerts to email plus Telegram when the site goes down
• Email alert on suspicious activity: 5+ failed logins from a single IP, file change inside wp-admin, new admin user created

Hanse Studio 800 PLN/month retainer monitoring: Telegram alerts on 5 patterns (failed login spike, file changes outside the update window, new admin user, plugin update available with a security advisory, site downtime). Response window: under 24 hours on business days, under 4 hours for a suspected breach (file changes or a new admin user).

What Hanse Studio does on the 800 PLN/month retainer

The Hanse Studio retainer for B2B clients covers all 10 steps above plus additional monthly activities. The scope below is exactly what we do for every retainer client:

• Monthly plugin audit: installed list plus version plus CVE check against the Patchstack DB
• Monthly security scan: Wordfence scan plus a manual file integrity check
• Backup verify: weekly verification that the backup ran plus quarterly test restore
• Plugin vulnerability check: subscription to Patchstack alerts, immediate response window for critical CVEs
• Response window: under 24 hours on business days for non-critical issues, under 4 hours for a suspected breach
• Quarterly review: PDF report with security status, recommendations plus a Telegram update

Clients who want the full scope without self-management: see the retainer scope or book a call about your site. A client without a retainer can also commission a one-off security audit from 1500 PLN (PDF report plus 1h call), more in our Elementor to Gutenberg migration runbook, where a security audit is phase 1 of every rebuild.

For a deeper threat landscape understanding we recommend the official documentation: WordPress.org hardening guide and the Patchstack Vulnerability Database for current CVE monitoring.

FAQ

Wordfence plugin or Cloudflare WAF: which to pick?

Cloudflare WAF if you already use Cloudflare for CDN and SSL (the most common scenario for a Hanse Studio client), because it acts at the edge before WordPress is even reached. Wordfence if budget is tight (the free tier suffices for SMBs) or if the client refuses to use a Cloudflare proxy. You can also combine them for layered defense: Cloudflare WAF at the edge plus Wordfence for plugin-level rules.

Is 2FA needed for content editors (editor, author roles)?

Yes, any user with dashboard access should have 2FA. An editor can edit posts and the media library, which is an attack surface for XSS injection or malicious upload. Author is less sensitive, but the standard rule is: 2FA for every user with capability edit_posts or higher.

Is Let’s Encrypt SSL enough for a WordPress site?

Yes, Let’s Encrypt yields an A grade on the SSL Labs test (with proper server configuration). Requirements: TLS 1.2 minimum (TLS 1.3 preferred), strong cipher suites, HSTS header with preload, SSL Full Strict mode if Cloudflare is proxying. An EV cert does not add security benefit, only a visual badge in the browser (deprecated in Chrome since 2019).

What to do after a breach: incident response procedure?

Procedure: 1) isolate (Cloudflare under attack mode or maintenance plugin), 2) identify scope (file changes, new admin users, malicious posts), 3) restore from a pre-incident backup, 4) audit logs (Wordfence, server access logs), 5) rotate every credential (WP admin, DB, FTP, API tokens), 6) patch the root cause vulnerability, 7) notify users if PII was compromised (GDPR 72h obligation). The full runbook is part of Hanse Studio retainers.

Next step: audit your site

If your WordPress site has 50+ plugins or has been running for 3+ years without a security audit, incident risk grows linearly with stack age. Hanse Studio runs a one-off security audit from 1500 PLN: a PDF report with findings, a prioritised remediation list, plus a 1h call covering the biggest risks and quick wins. Contact us for a quote, we reply within 24 hours on business days.