Check for recently created users you don’t recognize:

SELECT ID, user_login, user_email, user_registered
FROM wp_users
WHERE user_registered > '2025-12-01'
ORDER BY user_registered DESC;

Immediate mitigation options (prioritize these)

1. Temporarily disable or remove the WPlyr Media Block plugin until an official patch is released.
2. Restrict admin-level accounts: disable unused admin accounts, enforce unique strong passwords, and enable 2FA for all admin users.
3. Apply WAF/virtual patching rules to block requests containing suspicious characters in _wplyr_accent_color.
4. Sanitize existing stored values: remove or clean plugin options and meta values that contain HTML or script.
5. Implement a Content Security Policy (CSP) to limit inline script execution and reduce XSS impact.
6. Check for and remove unauthorized admin accounts, scheduled tasks, and altered files.

If you cannot remove the plugin immediately, virtual patching via a WAF is the fastest way to stop exploitation while you remediate.

WAF / Virtual patching: recommended rules and examples

Below are practical examples for ModSecurity and short-term server-side sanitization. Adapt to your WAF engine and test carefully in a staging environment before deployment.

1) ModSecurity examples

# Block requests where _wplyr_accent_color contains unsafe tokens
SecRule ARGS:_wplyr_accent_color "@rx (<|>|script|onmouseover|onerror|javascript:|data:)" \
    "id:1000011,phase:2,deny,status:403,log,msg:'Blocked suspicious _wplyr_accent_color input'"

# Allow only standard hex color format (3 or 6 hex chars, optional leading #)
SecRule ARGS:_wplyr_accent_color "!@rx ^#?([A-Fa-f0-9]{3}|[A-Fa-f0-9]{6})$" \
    "id:1000012,phase:2,deny,status:403,log,msg:'Blocked non-hex _wplyr_accent_color input'"

2) Broader admin POST blocking (use with care)

SecRule REQUEST_URI "@rx /wp-admin/|/admin-ajax.php" "chain,phase:2,deny,status:403,log,id:1000020,msg:'Blocked admin XSS attempt'"
  SecRule ARGS_NAMES|ARGS|REQUEST_HEADERS|REQUEST_BODY "@rx (|onerror=|onload=|javascript:|document.cookie|eval\()" "t:none"

3) Server-side PHP filter (temporary mitigation)

If you can add a must-use plugin or edit your theme’s functions.php, you can sanitize the parameter before it is saved. Example (temporary):

add_filter( 'pre_update_option_wplyr_settings', 'sanitize_wplyr_accent_color', 10, 2 );

function sanitize_wplyr_accent_color( $new_value, $old_value ) {
    if ( isset( $new_value['_wplyr_accent_color'] ) ) {
        $color = $new_value['_wplyr_accent_color'];
        // Keep only hex color values (#fff or #ffffff)
        if ( preg_match( '/^#?([A-Fa-f0-9]{3}|[A-Fa-f0-9]{6})$/', $color, $m ) ) {
            $new_value['_wplyr_accent_color'] = '#' . ltrim( $color, '#' );
        } else {
            // Remove invalid value or set default
            $new_value['_wplyr_accent_color'] = '';
        }
    }
    return $new_value;
}

Note: this is a temporary mitigation. The plugin should perform proper validation using WordPress helper functions such as sanitize_hex_color() or wp_kses(), and escape on output.

4) Content Security Policy (CSP)

Add a CSP header as part of defense-in-depth. Example:

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.example.com; object-src 'none'; base-uri 'self'; frame-ancestors 'none';

Test CSP carefully to avoid breaking admin UX.

Developer guidance: How plugin authors should fix this properly

The correct fix needs three elements: validate input, sanitize storage, and escape output.

1. Use WordPress helpers for validation: For color values, use sanitize_hex_color() or sanitize_hex_color_no_hash().

   $color = isset( $_POST['_wplyr_accent_color'] ) ? $_POST['_wplyr_accent_color'] : '';
   $color = sanitize_hex_color( $color ); // returns '#RRGGBB' or '' if invalid

2. Escape on output: Use esc_attr() or esc_html() when echoing into attributes or HTML.

   echo '
   ';

3. Avoid raw insertion into script contexts: If passing to JS, use wp_json_encode() and esc_js().

4. Verify nonces and capabilities: All admin POSTs should check check_admin_referer() and current_user_can().
5. Tests and security reviews: Add unit tests for sanitization/escaping and include a security review in release procedures.

Incident response checklist (if you suspect exploitation)

1. Isolate: Disable the vulnerable plugin and, if under active attack, put the site in maintenance mode and block public traffic if possible.
2. Preserve evidence: Take filesystem and database snapshots; export server and WAF logs for the period of suspected compromise.
3. Identify indicators: Search for
   Review My Order

   0

   Subtotal

   Taxes & shipping calculated at checkout

   Checkout