Developer guidance — fix the root cause

WAF rules buy time, but developers must remediate the vulnerable code. Share this checklist with your plugin/theme developers:

• Use prepared statements or the WPDB placeholders: $wpdb->prepare() for all SQL queries.
• Sanitize and validate all input: use esc_html(), esc_attr(), intval(), sanitize_text_field(), wp_kses_post(), and other WordPress sanitizers as appropriate.
• Escape on output: use the correct escaping function depending on context (HTML, attribute, JS, URL).
• Capability checks: every admin AJAX or REST endpoint must check current_user_can() and return 403 for insufficient permissions.
• Nonces: use wp_create_nonce() and verify with wp_verify_nonce() for state-changing actions.
• File upload validation: validate MIME type, file extensions and scan contents. Do not rely solely on file extension. Store uploaded files outside webroot or force downloads rather than execute them.
• Avoid including files based on user input.
• Default secure configuration: remove debug/test code and ensure error messages do not leak sensitive info.
• Automated tests: add unit and integration tests that include malicious input cases (XSS, SQLi, file upload).

Hardening checklist — site configuration & server-level

• Keep WordPress core updated. Automate minor updates where possible.
• Remove unused plugins and themes. Old code is commonly exploited.
• Disable the plugin/theme file editor: add to wp-config.php:

  define('DISALLOW_FILE_EDIT', true);

• Protect wp-config.php and .htaccess at the web server level. Example (Apache):

  
    order allow,deny
    deny from all
  

• Secure uploads: force uploads into a subfolder with strict permissions and limit allowed extensions.
• Implement strict file and directory permissions (e.g., 644 for files, 755 for directories).
• Use TLS everywhere and HSTS.
• Add security headers (CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy).
• Block access to readme.html and license.txt files exposing version info.
• Limit XML-RPC: disable it if not needed; otherwise rate-limit it.
• Use strong, unique admin credentials and enforce 2FA.
• Limit login attempts and block suspicious IPs.

Monitoring and detection — what to look for

Set up continuous monitoring and alerting for these signals:

• High volume of POST requests to plugin endpoints or admin-ajax.php.
• Requests containing PHP tags or shell-like payloads.
• Unexpected new admin user creation.
• File modifications to theme/plugin directories or uploads of .php files.
• Outbound connections from the server you didn't authorize (SSRF indicators).
• Unusual cron jobs or scheduled tasks.
• New files in wp-content that are not part of legitimate plugin/theme updates.

Log retention for at least 90 days is ideal for forensic analysis.

Incident response: compact runbook for suspected compromise

If you suspect a site has been compromised, execute the following steps in order:

1. Contain
   • Put the site into maintenance mode or block inbound traffic by IP range.
   • Change admin credentials and revoke any API keys.
   • Temporarily disable FTP/SSH access if possible.
2. Snapshot
   • Take a full file and DB snapshot for forensic analysis (store offline).
   • Preserve server logs and WAF logs.
3. Identify
   • Look for suspicious admin users, modified files, new PHP files in uploads, and scheduled tasks.
   • Check recent database changes for unauthorized edits.
4. Eradicate
   • Remove backdoors and unauthorized files.
   • Reinstall WordPress core, plugins, and themes from clean sources (do not trust backups without checking).
   • If you can’t confidently clean, rebuild from a known-good backup.
5. Recover
   • Restore a clean backup or redeploy a fresh site and migrate content.
   • Rotate all credentials and keys.
   • Re-enable services carefully and monitor.
6. Post-incident
   • Perform a root-cause analysis.
   • Implement additional WAF rules and hardening.
   • Report the vulnerability to the component maintainer responsibly (if applicable).
   • Consider a security audit or professional cleanup for complex breaches.

Long-term program: keep attackers off your road

• Monthly plugin/theme audits: identify end-of-life or rarely-updated components.
• Scheduled automated scans (weekly) plus manual quarterly reviews.
• Implement a change control process (test updates in staging before production).
• Maintain an incident response playbook and test it via tabletop exercises.
• Train content editors about suspicious links and social engineering risk.
• Engage a competent security team for managed detection if you manage multiple sites or high-value properties.

Sample detection and forensic indicators to share with your team

Provide this list to operations and dev teams for quick checks after an alert:

• Files in /wp-content/uploads/ containing .
• New scheduled events containing suspicious functions (wp_get_schedule, wp_schedule_event).
• DB rows in wp_users with user_login not matching known patterns.
• Unexpected outbound HTTP(s) requests from the server (check webserver logs or netstat).
• Access logs showing consistent POSTs to specific plugin endpoints from same IP ranges.
• Requests that include ..%2f or ..%252f (encoded path traversal).
• Unusually large numbers of 404 responses followed by successful POSTs (probing then exploit).