When allowing a subset of HTML, define allowed tags and attributes and use wp_kses():

$allowed = array(
  'a' => array(
    'href' => true,
    'title' => true,
  ),
  'strong' => array(),
  'em' => array(),
);

echo wp_kses( $input, $allowed );

Developer checklist:

• Escape on output, sanitize on input.
• Use nonces and capability checks for any state-modifying actions.
• Avoid echoing raw $_GET/$_REQUEST/$_POST values directly into templates.

Detecting exploitation and hunting for signs of attack

After patching or applying temporary controls, hunt for indicators of exploitation:

1. Web server logs: look for query strings containing encoded characters (e.g., %3C, %3E, %22) or suspicious tokens like document.cookie or eval(.
2. Application logs: anomalous requests to pages that reflect parameters; spikes in errors or unusual referrers.
3. User/activity logs: unexpected new users, new admin accounts, or changes in user roles.
4. Scheduled tasks: new cron jobs or unexpected scheduled actions.
5. Browser-side reports: users reporting popups, redirects, or strange login prompts.

Incident response checklist (if you suspect exploitation)

1. Consider putting the site into maintenance mode to limit further interactions while investigating.
2. Collect and preserve logs and make a full backup for forensic analysis.
3. Rotate administrative passwords and API keys (WordPress admin accounts, database credentials, hosting control panels, SFTP).
4. Run multiple malware scanners and manually inspect files for backdoors or obfuscated code (look for base64_decode, eval, unusual concatenation).
5. Remove unexpected admin users and audit user roles.
6. If the compromise is extensive, restore from a verified clean backup.
7. Reissue any potentially compromised tokens or credentials.
8. Communicate to stakeholders if data or accounts were affected.
9. Engage a professional incident response team or your hosting provider if you require deeper investigation or remediation assistance.

Hardening recommendations beyond patching

• Apply a Content Security Policy (CSP) to restrict script sources and inline execution. Start in report-only mode to tune the policy:

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

• Set cookie flags: ensure session cookies use HttpOnly, Secure (with HTTPS), and appropriate SameSite settings.
• Disable file editing from the WordPress admin panel: define('DISALLOW_FILE_EDIT', true);
• Adopt the principle of least privilege for user accounts; avoid unnecessary admin access.
• Maintain regular backups and a tested restore process.
• Use staging environments for theme and plugin updates and test changes before production rollout.

Why WAF / virtual patching helps

A WAF can reduce exposure by blocking exploit attempts before they reach vulnerable code. For reflected XSS, a properly tuned WAF can:

• Block malicious query strings and payloads in real time.
• Provide logging and visibility for hunting and forensic work.
• Allow virtual patching while you validate and deploy official vendor fixes.

Operational guidance for WAF rule deployment

• Start with rules running in log/monitor mode for 48–72 hours to gather false-positive data.
• Log blocked requests to a central location for analysis (WAF logs, SIEM, or host logs).
• Whitelist trusted IPs or trusted paths if legitimate traffic is impacted.
• Keep a changelog of rule modifications (who changed what and why) to simplify rollback and audits.

Long-term secure development practices

• Escape output using context-appropriate functions: esc_html(), esc_attr(), esc_url(), esc_js().
• Validate and sanitize inputs at acceptance and prior to storage: sanitize_text_field(), wp_kses_post(), absint() as appropriate.
• Use capability checks and nonces for actions that modify site state.
• Review code for direct echoes of $_GET, $_REQUEST, or $_POST.
• Integrate security linters and automated tests that simulate malicious inputs into CI pipelines.

Developer quick checklist

• [ ] Replace any echo $variable; in templates with the appropriate escaping function.
• [ ] Remove or sanitize direct usage of $_GET/$_REQUEST in templates.
• [ ] Ensure stored user input is sanitized and escaped on output.
• [ ] Add CSP as a defense-in-depth control.
• [ ] Review and restrict third-party scripts and inline script usage.
• [ ] Implement secure cookie flags (HttpOnly, Secure, SameSite).

Final words — what to do right now

1. Update the Reebox theme to version 1.4.8 or later as soon as you can, ideally via a tested staging workflow.
2. If you cannot update immediately, enable request filtering or WAF rules (virtual patching) that block common reflected XSS patterns and monitor for false positives.
3. Scan your site for indicators of compromise and review logs for suspicious query strings.
4. Apply longer-term hardening: proper escaping, CSP, secure cookie settings, and least-privilege user roles.
5. If you require assistance, contact a trusted security professional or your hosting provider for incident response and remediation support.

Resources & references