Also search for event handler attributes such as “onerror=”, “onload=”, “onclick=”, or “javascript:” URIs and data: URIs.

2. File system scan

Use a malware scanner to check for modified core files, unexpected PHP files in uploads, or newly created admin‑facing PHP files. Compare file hashes against clean WordPress/core/plugin packages.

3. Access logs

Inspect web server access logs for requests containing suspicious payloads to booking plugin endpoints or repetitive attempts with encoded payloads (for example, “%3Cscript%3E”).

4. Admin activity logs

Review admin logins for unfamiliar IPs, suspicious user creations, role changes, or actions taken at unusual times.

5. Behavioral signs

Look for unexpected redirects, injected banners/ads, unexplained SEO spam pages, or user reports of redirects/ads.

If you find evidence of injection, assume potential compromise and follow the incident response steps below.

Incident response: If you think your site was compromised

1. Isolate the site (short term)
   • Put the site in maintenance mode or restrict access via IP allowlist to limit further damage.
2. Preserve evidence
   • Back up the current site state (DB + files) and secure copies offline for forensic analysis.
3. Rotate secrets and credentials
   • Change all admin passwords, FTP/SFTP, SSH keys, and any API keys used by the site. Replace salts in wp-config.php.
4. Clean or rebuild
   • Prefer restoring from a clean backup taken before the compromise. If unavailable, remove injected content manually and reinstall affected plugins/themes from official sources.
   • Scan and compare file hashes against clean WordPress core and plugin packages.
5. Audit users and permissions
   • Remove unknown admin users and check roles. Enable two‑factor authentication for all admin accounts.
6. Re-run security scans and monitor logs
   • After remediation, run full malware scans and monitor logs closely for recurrence.
7. Post‑mortem
   • Identify the root cause and put processes in place to prevent recurrence (patch management, staging testing, monitoring).

If you lack in‑house expertise, engage experienced WordPress security professionals for a full forensic investigation and remediation.

Recommendations for long-term hardening (beyond immediate fixes)

• Keep WordPress core, themes, and plugins updated regularly.
• Limit plugins to necessary, reputable ones; remove inactive plugins.
• Apply the principle of least privilege: grant only required roles/capabilities.
• Enforce strong passwords and enable two‑factor authentication for admin accounts.
• Set secure cookie flags (HttpOnly, Secure) and consider SameSite settings.
• Prevent direct file editing in wp-admin by adding to wp-config.php:

  define('DISALLOW_FILE_EDIT', true);
  define('DISALLOW_FILE_MODS', true);

• Implement Content Security Policy (CSP) to reduce the impact of reflected/stored XSS. Start with report-only mode to tune:

  Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-'; object-src 'none'; base-uri 'self'; frame-ancestors 'none';

  Tuning CSP for WordPress requires careful testing; use Content-Security-Policy-Report-Only initially.

• Enable HTTP security headers: X-Content-Type-Options: nosniff; Referrer-Policy; X-Frame-Options (DENY or SAMEORIGIN); HSTS as appropriate.
• Set up file integrity monitoring (FIM), monitor access logs and admin activity, and run scheduled vulnerability scans.

WAF mitigation: practical rules and examples

If you cannot immediately update to 1.2.47, apply targeted WAF rules to block or mitigate exploit attempts. The patterns below are defensive; tune to your environment to avoid false positives. Do NOT publish or use exploit payloads.

Example ModSecurity rule (generic XSS blocking)

SecRule REQUEST_HEADERS:Content-Type "^(?:application/x-www-form-urlencoded|multipart/form-data)" \
 "phase:2,rev:2,severity:2,log,deny,id:1000010,msg:'Block XSS suspects: script or event handlers',\
  chain"
  SecRule ARGS "(<\s*script\b|javascript:|data:text/html|on\w+\s*=)" \
  "t:none,ctl:ruleRemoveById=981176,logdata:'%{MATCHED_VAR}',capture"

Notes:

• ARGS inspects all request arguments.
• This is aggressive and may block legitimate HTML inputs; restrict it to the plugin path if possible.

Nginx location-specific blocking example

location ~* /wp-admin/admin-ajax.php {
    if ($request_uri ~* "action=wp_time_slots") {
        if ($request_body ~* "(%3Cscript%3E|