Also search for markers like onerror=, onload=, and javascript:. Review POST requests to admin-ajax.php or plugin endpoints in access logs and inspect page output via browser developer tools for unexpected inline scripts or DOM changes. Focus on plugin-owned fields and filter names where HTML is not expected.

Developer remediation — best practices and example hardening code

Core rules:

• Sanitize input before storing if HTML is not intended.
• Escape output when rendering data in any HTML context.

If a field should be plain text, strip HTML on input. If limited HTML is required, use a strict whitelist (wp_kses) and escape appropriately when outputting.

Examples:

Strict sanitize on save (plain text):

if ( isset( $_POST['name'] ) ) {
    // Strip tags and sanitize as text before saving
    $name = sanitize_text_field( wp_strip_all_tags( wp_unslash( $_POST['name'] ) ) );
    // Save $name to the DB using update_option / update_post_meta etc.
}

If limited HTML is required (whitelist):

$allowed_tags = array(
    'a' => array( 'href' => array(), 'title' => array(), 'rel' => array() ),
    'strong' => array(),
    'em' => array(),
    'span' => array( 'class' => array() ),
);

if ( isset( $_POST['name'] ) ) {
    $name_raw = wp_unslash( $_POST['name'] );
    $name = wp_kses( $name_raw, $allowed_tags );
    // Save $name safely
}

When outputting:

// For HTML element content
echo esc_html( $name );

// For HTML attribute (e.g., value="")
echo esc_attr( $name );

// If intentionally allowing sanitized HTML (processed with wp_kses)
echo $name; // Only if $name was properly sanitized and is safe for this context

AJAX endpoint defenses (capability and nonce checks):

add_action( 'wp_ajax_my_plugin_save_filter', 'my_plugin_save_filter' );
function my_plugin_save_filter() {
    // Check capability — consider disallowing Contributor
    if ( ! current_user_can( 'edit_posts' ) ) {
        wp_send_json_error( 'Insufficient privileges' );
    }

    // Check nonce
    if ( ! isset( $_POST['nonce'] ) || ! wp_verify_nonce( $_POST['nonce'], 'my_plugin_nonce' ) ) {
        wp_send_json_error( 'Invalid nonce' );
    }

    // Sanitize input and save (use sanitize_text_field or wp_kses as described)
}

Where appropriate, raise the capability required for creating or editing plugin configuration (e.g., to Editor or a custom capability) or add an approval workflow for new configurations.

WAF / virtual patching guidance (temporary protection)

If you operate a web application firewall, you can use it as a temporary virtual patch while preparing to update. Test rules carefully to avoid breaking legitimate functionality.

Rule concepts (defensive, not exploit patterns):

1. Block or sanitize requests to the plugin’s AJAX endpoints where the name parameter contains script tags or suspicious handlers (e.g., <script, javascript:, onerror=).
2. Apply regex matches to detect patterns such as (script|onerror|onload|javascript:|document\.cookie) in POST payloads for the plugin action.
3. If a plugin-specific endpoint receives a name value containing angle brackets, consider rejecting the request or stripping tags server-side.
4. Monitor and alert on blocked attempts, and log raw requests, IPs, user agents, and user accounts for investigation.

WAF mitigations reduce risk but do not replace patching. Treat them as stopgap controls and validate rules in a logging mode before enforcement to avoid false positives.

How to search the site for stored payloads and clean them

1. Create backups of database and files before any cleanup.
2. Search for suspicious strings (script tags, event handlers) in DB tables:
   • Posts and postmeta: wp_posts.post_content, wp_postmeta.meta_value
   • Terms and termmeta: wp_terms.name, wp_termmeta.meta_value
   • Options: wp_options.option_value
   • Plugin tables: check plugin-specific tables that may store filter names.
3. WP-CLI examples to list matches:

# Search postmeta
wp db query "SELECT post_id, meta_key, meta_value FROM wp_postmeta WHERE meta_value LIKE '%

4. Remove or sanitize matches:
   • If the field should be plain text, strip tags with wp_strip_all_tags() and update entries.
   • For large sites, script cleanup with WP-CLI or a safe PHP script executed under WP-CLI is practical.
5. Re-scan the file system for unexpected or new files and scan for webshells.
6. Rotate credentials for privileged accounts and any service/API keys.
7. If active compromise evidence exists (backdoors, dropped files), consider restoring from a pre-exploitation backup and perform a full incident response.