Simple regex to detect non-numeric or suspicious values:

/<|>|onerror=|javascript:|<script|%3Cscript/i

Heuristics:

• If selector_height must be numeric, block values containing alphabetic characters or angle brackets.
• Only apply tighter rules to endpoints that change plugin settings or are accessible to authenticated users.
• Log and alert on blocked attempts so you can investigate the source IPs and payloads.

How to clean up stored payloads

1. Identify all storage locations for selector_height (postmeta, options, widget_data).
2. Manually replace or sanitize unsafe values from the WordPress admin or via SQL/CLI if multiple rows are affected.
3. Take a full backup before running any automated database fixes.

Example SQL (MySQL/MariaDB with REGEXP_REPLACE support):

UPDATE wp_postmeta
SET meta_value = REGEXP_REPLACE(meta_value, '<[^>]*>', '')
WHERE meta_value LIKE '%selector_height%'
  AND (meta_value LIKE '%<script>%'
       OR meta_value LIKE '%onerror=%');

Example WP‑CLI/PHP conceptual snippet (run carefully):

// Run this carefully in a plugin or WP-CLI script
$meta_rows = $wpdb->get_results("
  SELECT meta_id, meta_value FROM {$wpdb->postmeta}
  WHERE meta_value LIKE '%selector_height%'
");
foreach ($meta_rows as $row) {
  $clean = wp_kses( $row->meta_value, array() ); // remove all tags
  $wpdb->update( $wpdb->postmeta, array('meta_value' => $clean), array('meta_id' => $row->meta_id) );
}

Always validate remediation on a staging copy before applying to production.

Fix for developers and plugin authors (hardening)

Plugin developers should adopt a strict input‑first approach: validate → sanitize → store → escape on output. Key practices:

• Validate inputs strictly — if selector_height is numeric, coerce with intval(), absint() or filter_var(..., FILTER_VALIDATE_INT) and reject invalid values.
• Sanitize before storing — use sanitize_text_field() or wp_kses() with an allowlist if HTML is permitted.
• Escape on output — use esc_attr() for attributes and esc_html() or wp_kses_post() for body content.
• Capability checks and nonces — ensure only appropriate capabilities can change settings and verify nonces on state-changing requests.
• Audit admin pages — limit what Contributors may change; do not accept arbitrary parameters that will be rendered later.
• Logging — record unexpected input patterns and notify administrators when lower-privileged users supply suspicious values.

Conceptual safe-handling example (PHP):

// Suppose selector_height should be an integer
if ( isset($_POST['selector_height']) ) {
    if ( ! current_user_can('edit_posts') ) {
        wp_die('Insufficient privileges');
    }
    if ( ! wp_verify_nonce( $_POST['_wpnonce'], 'bible_supersearch_save' ) ) {
        wp_die('Invalid request');
    }

    $height = intval( $_POST['selector_height'] ); // force integer
    update_option( 'bss_selector_height', $height );
}

// Output
$height = intval( get_option( 'bss_selector_height', 300 ) );
echo 'style="height:' . esc_attr( $height ) . 'px;"';

Monitoring and longer‑term risk reduction

• Account hygiene: limit Contributor accounts, audit activity, require strong passwords and 2FA for elevated users.
• Editorial moderation: prevent Contributor-submitted content from being rendered publicly until approved.
• Virtual patching: use WAF/hosting provider rules to block exploitation patterns while applying permanent fixes.
• Automated integrity checks: monitor file changes and scan databases for unexpected HTML in numeric fields.
• Logging and SIEM: forward logs to a central system so you can correlate blocked requests with subsequent activity.

For incident responders: steps to investigate a compromise

1. Determine scope — locate instances of selector_height and check for injected HTML/JS; search for new admin users, changed files, and scheduled tasks.
2. Quarantine — deactivate affected plugins or restrict admin access; block suspicious IPs.
3. Clean and restore — remove stored payloads and restore modified files from trusted backups or reinstall from official sources.
4. Credentials — force password resets for administrators and rotate API keys.
5. Follow-up — monitor for reappearance of payloads and verify no remaining backdoors are present.

Recommended WAF rule checklist (quick reference)

• Block requests where selector_height contains <, >, or script.
• If selector_height should be numeric, block any non-digit characters (except allowed units like px if applicable).
• Log and alert on blocked events; investigate sources that trigger multiple blocks.
• Rate-limit or block anonymous users accessing plugin admin endpoints.
• Consider geo-throttling or IP reputation blocking if appropriate for your site.

Developer checklist to prevent similar vulnerabilities

• Validate server-side; do not rely solely on client-side checks.
• Sanitize inputs on entry and escape on output.
• Use capabilities and nonces for state changes.
• Prefer numeric conversions for numeric fields.
• Unit test and fuzz form fields for malicious payloads.
• Implement Content Security Policy (CSP) headers to reduce impact of XSS in browsers.

Communications templates

Sample message to contributors while remediation is in progress:

We're applying an urgent security update to a third‑party plugin that may affect some draft content. Please do not publish new posts or modify widgets until IT confirms the update is complete. If you notice unusual behavior in the editor (popups, redirects), log out immediately and change your password.

Sample message to administrators after cleanup:

The Bible SuperSearch plugin was updated to 6.1.0 to address a stored XSS vulnerability. We've scanned for and removed suspicious payloads and rotated administrative sessions. Please reset your password and enable two‑factor authentication if you haven't already. We will continue to monitor the site for anomalies.

Final priorities — immediate checklist

1. Update Bible SuperSearch to 6.1.0 or later immediately.
2. If you cannot update now, deactivate the plugin or ask your hosting provider to apply WAF rules or virtual patching.
3. Audit Contributor and other lower‑privileged accounts — remove or lock down unnecessary users.
4. Search and clean your database for stored payloads; inspect plugin settings, widget data, postmeta, and wp_options.
5. Harden the site: strict input validation, escaping on output, and strong access controls.
6. Maintain continuous monitoring with file integrity checks, WAF logs, and periodic malware scans.

If you require assistance for update, custom WAF rule creation, or a guided cleanup process, engage a trusted security consultant or your hosting provider's incident response service. For organisations in Hong Kong and the surrounding region, consider contacting a local security practice experienced with WordPress incident response.

Closing note (from a Hong Kong security perspective): treat this vulnerability as a prompt to tighten operational controls around low‑privileged accounts and to strengthen the input/output hygiene in plugins. Even lower‑severity stored XSS issues can yield high impact in multi‑author environments common to media and community sites. Prioritise patching and quick containment actions today.

Stay vigilant,
Hong Kong Security Expert