If you operate an application-level filter, create a rule to forbid HTML tags or on* attributes inside the target parameter and either reject or sanitise them before saving.

Safe remediation code snippets (plugin-level fixes)

If you maintain the affected plugin and want a quick remediation before an upstream patch, sanitise the target parameter on save and escape on output.

Sanitise before saving:

if ( isset( $_POST['target'] ) ) {
    // Remove HTML tags entirely if this parameter is meant to be plain text
    $target_clean = sanitize_text_field( wp_unslash( $_POST['target'] ) );

    // OR: allow only safe HTML using wp_kses
    $allowed = array( 'a' => array( 'href' => true, 'title' => true ) );
    $target_clean = wp_kses( wp_unslash( $_POST['target'] ), $allowed );

    update_post_meta( $post_id, 'plugin_readme_target', $target_clean );
}

Output with safety:

$stored = get_post_meta( $post_id, 'plugin_readme_target', true );
// Use esc_attr if printing into an attribute, or esc_html if in text node
echo esc_html( $stored );

If target is used to build a URL, validate with esc_url_raw() on save and esc_url() on render.

Incident response — when you suspect compromise

If you find evidence of exploitation:

1. Isolate the site: Put the site into maintenance mode and block public access if feasible.
2. Snapshot and backup: Create a full backup (files and DB) before making changes.
3. Clean injected content: Remove malicious HTML from posts, postmeta and options. Use SQL updates carefully and only after backing up.
4. Audit users and reset credentials: Reset admin passwords, force password resets for privileged accounts, and revoke suspicious admin users.
5. Scan for persistence: Check theme and plugin files for new or modified files, scheduled tasks (wp_cron), and wp-config.php for added code.
6. Reinstall plugins/themes from trusted sources: Replace plugin files with fresh copies from the official WordPress repository after confirming the plugin version is untampered.
7. Restore if necessary: If you cannot clean safely, restore from a known-good backup and apply WAF rules until a patch is available.
8. Consider professional response: For large or sensitive sites, engage incident-response specialists.

Recommendations for site owners and hosts

• Limit Contributor capability where feasible. Require moderator review of submitted content on community sites.
• Enable multi-factor authentication for all administrators.
• Use host-level or application-level filtering that supports virtual patching while awaiting official fixes.
• Keep audit logs and activity monitoring active. Detecting suspicious admin page views after contributor updates is a key indicator.
• Educate editors and admins to avoid previewing untrusted content in admin consoles until content has been sanitized or reviewed.

For plugin authors — guidelines to prevent similar issues

• Treat all user input as hostile, even from authenticated users.
• Assume that stored data may be rendered in contexts that allow script execution (admin pages, front-end, REST responses).
• Provide escaping and sanitising options in code; do not rely solely on output context.
• Document expected input for each field and enforce validation on save.
• Consider storing both raw data and a sanitized/rendered variant — ensure the sanitized variant is used for presentation.
• Conduct threat modelling: consider where saved plugin metadata might later be rendered in admin screens accessed by privileged users.

Example detection regexes and DB-SQL queries

Quick regex examples (for log scanning or SIEM):

• Detect script tag: (?i)(<|%3[cC])\s*script
• Detect event handlers: (?i)on[a-z]+\s*=
• Detect javascript: protocol: (?i)javascript\s*:
• Detect double-encoding: (?i)%25[0-9a-f]{2}

SQL search examples:

-- Find meta values with html/script content
SELECT meta_id, post_id, meta_key, meta_value
FROM wp_postmeta
WHERE meta_value REGEXP '(?i)

SecRule REQUEST_METHOD "@streq POST" "id:100200,phase:2,pass,nolog,chain"
  SecRule ARGS:target "(?i)(%3C|<)\s*(script|img|iframe|svg|object)|javascript:|on[a-z]{1,20}\s*=" "id:100201,phase:2,deny,status:403,msg:'Aggressive protection - blocked possible stored XSS in target parameter'"

# This drops POSTs that include script-like content in target. If your site legitimately posts HTML in 'target', use a less aggressive rule that logs and alerts first.