WordPress Security Hub

This hub centralizes the highest-impact WordPress security content for teams who need to reduce risk quickly and prove progress to stakeholders. WordPress powers over 40% of the web, making it the most targeted CMS. Most compromises come from three vectors: outdated plugins with known CVEs, exposed admin panels without MFA, and misconfigured wp-config.php with debug mode on or secrets accessible.

Start here: highest-impact WordPress controls

Read these in order for systematic risk reduction:

• WordPress Hardening Roadmap 2026: 30-60-90 Day Plan — structured plan from critical risk reduction through operational maturity.
• WordPress Security Checklist 2026: 25 Steps — complete checklist covering plugins, themes, auth, files, headers, and monitoring.
• WordPress Malware Removal: Step-by-Step Cleanup Guide — if you are already compromised, start here.
• Hardening wp-config.php: Essential Security Constants — copy-paste constants that disable debug, enforce SSL, and restrict file edits.

Deep-dive hardening guides

• Security Headers Checklist 2026: CSP, HSTS, Cookie Hardening — browser-level attack surface reduction for WordPress sites.
• Pre-Launch Security Checklist — verify WordPress security before going live or after major migrations.
• How to Fix Exposed .env Files — relevant for WordPress + Bedrock setups using Composer and .env configuration.

Why WordPress is the most-targeted CMS

WordPress's dominance — powering over 40% of all websites — makes it the primary target for automated attack tooling. Every attacker knows the default paths: /wp-login.php, /wp-admin/, xmlrpc.php, and wp-config.php. Automated scanners continuously probe these paths across millions of domains, meaning the window between a plugin vulnerability being published and the first exploit attempt is measured in hours, not days.

The three most common WordPress compromise paths are:

• Vulnerable plugins and themes (90%+ of incidents): Attackers index the WPScan vulnerability database and target sites running known vulnerable versions. Outdated plugins with unauthenticated file upload, SQL injection, or XSS vulnerabilities are the leading entry point.
• Credential brute-force against wp-login.php: Without rate limiting and MFA, login pages are continuously targeted with credential stuffing from breach databases. The default admin username dramatically increases attack surface.
• Exposed configuration and backup files: Accessible wp-config.php, database dumps, and backup archives expose credentials that give attackers direct database access without needing to exploit any vulnerability.

Critical security constants every WordPress site needs

These wp-config.php constants should be set on every production WordPress installation. They disable dangerous default behaviors that are frequently exploited:

define( 'DISALLOW_FILE_EDIT', true );       // Disable theme/plugin editor in admin
define( 'DISALLOW_FILE_MODS', true );       // Block all plugin/theme installs from admin
define( 'FORCE_SSL_ADMIN', true );          // Force HTTPS for all admin sessions
define( 'WP_DEBUG', false );                // Disable debug output in production
define( 'WP_DEBUG_LOG', false );            // Prevent debug.log file creation
define( 'DISALLOW_UNFILTERED_HTML', true ); // Restrict raw HTML in posts

See the full reference with explanations in the wp-config.php hardening guide.

Plugin security audit process

Plugin vulnerabilities are the dominant WordPress attack vector. A systematic audit process reduces the risk from this vector significantly:

• Step 1 — Inventory: List all installed plugins and themes with their versions. Use WP-CLI: wp plugin list --format=table.
• Step 2 — Vulnerability check: Cross-reference each plugin against the WPScan vulnerability database. Any plugin with a known unpatched CVE should be deactivated immediately.
• Step 3 — Update or replace: Update vulnerable plugins immediately. If no patch is available, find an actively maintained alternative or implement a WAF rule to block the attack vector temporarily.
• Step 4 — Remove unused: Deactivated plugins are still scannable and still represent attack surface. Remove anything not actively in use.
• Step 5 — Subscribe to alerts: Set up WPScan API monitoring or Wordfence Threat Intelligence for your installed plugin list so new CVEs trigger immediate notifications.

Protecting wp-login.php from brute force

The WordPress login page is attacked continuously. Basic protections reduce exposure dramatically without affecting legitimate users:

# Add to .htaccess — restrict wp-login.php to your IP
<Files wp-login.php>
  Order deny,allow
  Deny from all
  Allow from YOUR.OFFICE.IP.ADDRESS
</Files>

# Block XML-RPC completely (if not using Jetpack/WP mobile app)
<Files xmlrpc.php>
  Order deny,allow
  Deny from all
</Files>

If IP restriction is not practical (remote teams, dynamic IPs), use a security plugin with rate limiting and MFA as an alternative. The combination of MFA + 5-attempt lockout eliminates credential stuffing risk effectively.

WordPress file permissions: the correct configuration

Incorrect file permissions are a persistent WordPress vulnerability that allows attackers who gain limited access to escalate privileges by modifying PHP files. The principle of least privilege applies directly to the filesystem.

# Correct file permission model for WordPress
# Files: 644 — owner can read/write, group/others read only
find /var/www/html -type f -exec chmod 644 {} \;

# Directories: 755 — owner can read/write/execute, others read/execute
find /var/www/html -type d -exec chmod 755 {} \;

# wp-config.php: 640 or 600 — only owner can read (no group, no others)
chmod 640 /var/www/html/wp-config.php

# Uploads directory: 755 — writable by web server user for media uploads
chmod 755 /var/www/html/wp-content/uploads

# NEVER set 777 — this grants write access to all users on the server

After setting permissions, verify that the web server user (typically www-data) owns the files, not root. WordPress's file editor should be disabled via define('DISALLOW_FILE_EDIT', true) regardless of permissions — this adds a second layer preventing browser-based PHP modification.

WordPress malware recovery: what to do after a compromise

If your WordPress site has been compromised, recovery follows a specific sequence. Skipping steps creates re-infection risk.

1. Take the site offline: Prevent the compromised site from serving malware to visitors or being used for outbound attacks. Enable maintenance mode or block public access at the server level.
2. Preserve evidence: Before making changes, export access logs, error logs, and a full site snapshot. These are required for post-incident analysis and may be required for insurance claims or legal proceedings.
3. Identify infection scope: Scan all PHP files for injected code using grep -r "eval(base64_decode" /var/www/html and grep -r "base64_encode" /var/www/html --include="*.php". Check wp-includes and wp-admin — malware frequently hides in core directories.
4. Restore from clean backup: A known-clean backup from before the compromise is the fastest and most reliable recovery path. Restoring from backup eliminates malware that was injected into database content or obscured in modified files.
5. Rotate all credentials: Database password, WordPress admin passwords, FTP/SSH credentials, API keys in wp-config.php, and hosting panel passwords. The attack vector likely involved one of these — all must be rotated.
6. Identify and patch the entry point: Review access logs for the request that introduced the malware. Common entry points: vulnerable plugin or theme, weak admin password, outdated WordPress core, or a compromised hosting account. Patch the vulnerability before bringing the site back online.
7. Re-scan before going live: Run a full external scan and a server-side malware scan after restoration. Verify no backdoors remain before returning to production. See the full guide: WordPress malware removal guide.

WordPress security monitoring: what to track

Reactive security (responding to incidents after they happen) is significantly more expensive than proactive monitoring. These are the minimum monitoring controls for production WordPress sites.

• Failed login monitoring: Any spike in failed logins to /wp-login.php indicates a brute-force or credential stuffing attack in progress. Alert threshold: more than 20 failures per minute from any IP.
• File integrity monitoring: Core WordPress files should not change between updates. Monitor for unexpected modifications to wp-includes/ and wp-admin/ — changes indicate malware injection.
• Plugin CVE monitoring: Subscribe to Wordfence threat intelligence or WPScan vulnerability database to receive alerts when CVEs are published for plugins you have installed.
• Weekly external scans: Run the AI QA Monkey WordPress scanner weekly to detect new exposures, changed headers, or newly accessible sensitive files.
• Uptime + response anomaly monitoring: Sudden increases in page size, response time, or redirect chains can indicate malware injection. Uptime tools that alert on anomalies provide early detection.

Incident and operations

• Incident Response Plan Template — triage, containment, and recovery process for WordPress compromise events.
• Vulnerability Management SLA Template — define remediation timelines for plugin and theme CVEs.
• Website Security KPI Dashboard — track MTTR, SLA breach rate, and coverage across your WordPress estate.

Explore related hubs

• API Security Hub
• Compliance Security Hub