If suspicious entries are found, export them and treat the site as potentially compromised until cleaned.

Immediate remediation steps (what to do right now)

Prioritise these actions:

1. Update the plugin to 4.0.6 immediately. This is the primary remediation.
2. If you cannot update immediately:
   • Deactivate Simple Download Monitor temporarily.
   • Remove or restrict Contributor editing privileges for plugin custom fields.
   • Hide or stop rendering the affected custom fields in your theme/templates until patched.
3. Audit user accounts: review Contributor accounts and recent edits; reset passwords for suspicious accounts and high-privilege users if needed.
4. Run a full malware scan and file integrity check across files and database.
5. Search the database for injected scripts (use the queries above) and remove confirmed malicious entries. Back up before changes.
6. Apply temporary server-side filtering or WAF rules to block payloads containing script tags or suspicious event attributes while you update.
7. Check server logs for unusual POSTs from Contributor accounts and anomalous behaviour.
8. If you suspect full compromise, restore from a clean backup and rotate secrets (database passwords, API keys, admin passwords).

Recommended long-term hardening (secure coding and configuration)

• Principle of least privilege:
  • Give Contributors only the capabilities they need. If they do not need to add custom fields, remove that capability.
  • Limit unfiltered_html to Administrators.
• Sanitize input and escape output:
  • Use server-side sanitization before storing: sanitize_text_field() for plain text; wp_kses()/wp_kses_post() for limited HTML.
  • Escape on output: esc_html(), esc_attr(), and wp_kses_post() where appropriate.
• Capability checks: validate current_user_can() before allowing edits to data rendered for others and enforce nonces on form submissions.
• Avoid printing raw meta values into templates. Sanitize and escape values before output.
• Audit third-party plugins before installing: check last update date, active installs, and known security history.
• Enforce secure cookie flags (HttpOnly, Secure, SameSite) and adopt a Content Security Policy (CSP) to mitigate impact.

Example temporary virtual patch / WAF rule (pseudo and explanation)

If you cannot patch immediately, a temporary virtual patch can reduce risk. Translate this conceptual rule to your reverse proxy, WAF, or application-layer filtering:

IF request.method IN (POST, PUT)
AND (
  request.uri CONTAINS '/wp-admin/' OR request.uri CONTAINS '/wp-json/'
  OR request.body MATCHES /(<\s*script\b|onerror\s*=|onload\s*=|javascript:)/i
)
THEN block AND log

Explanation:

• Block POST/PUT requests that include script tags, javascript: URIs, or event handler attributes — common XSS markers.
• Scope the rule to admin and REST endpoints that accept meta values.
• Log blocked requests for audit and forensics.

Caveats: tune patterns to avoid false positives and complement virtual patching by removing stored payloads and applying the vendor patch as soon as possible.

Example code fixes for plugin/theme authors

Ensure output escaping in templates. Examples:

ID, 'sdm_custom_field', true );

// If you expect plain text
echo esc_html( sanitize_text_field( $meta_value ) );

// If you allow limited HTML (carefully), use wp_kses_post with a whitelist:
echo wp_kses_post( $meta_value );
?>

Restrict allowed tags when limited HTML is required:

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

echo wp_kses( $meta_value, $allowed_tags );

Always escape attribute outputs:

$label = get_post_meta( $post->ID, 'sdm_label', true );
printf( '', esc_attr( sanitize_text_field( $label ) ) );

Remediation playbook after compromise

1. Isolate the site: enable maintenance mode or otherwise prevent public access to stop further damage.
2. Take a full backup (files + DB) for forensic analysis — preserve this copy.
3. Update affected plugin(s) to the patched version.
4. Remove discovered payloads from the database; export and edit copies safely rather than making blind deletions.
5. Rotate all admin and privileged user passwords; force password resets where appropriate.
6. Rotate keys and secrets stored in configuration files and third-party integrations.
7. Scan site files for webshells and unfamiliar PHP files; replace suspicious files with clean vendor copies.
8. Review server logs to identify attacker activity and assist threat hunting.
9. Harden accounts and enforce editorial workflows where contributors submit drafts for editorial review.
10. Restore from a known clean backup if longstanding undetected compromise is suspected.

If required, engage a professional incident response service to preserve evidence and complete a thorough cleanup.

Why a managed WAF and malware scanner help

A managed WAF and automated scanning provide operational advantages when dealing with plugin vulnerabilities:

• Rapid rule deployment: virtual patches can block exploit patterns while patches are rolled out.
• Tuned signatures: targeted rules can reduce false positives and protect specific endpoints.
• Automated scanning: detect stored scripts and suspicious modifications in files and databases.
• Monitoring and alerts: immediate notice of suspicious activity.
• Incident support: some providers offer remediation and forensic assistance as part of higher-tier services.

Note: a WAF or scanner is an additional layer — not a replacement for updating the plugin.

Where to get professional help

If you need external assistance, engage reputable incident response or WordPress security professionals. When selecting help, prefer providers who:

• Preserve evidence and provide forensic reporting.
• Offer controlled remediation (file replacement, database cleaning) rather than destructive blanket deletes.
• Provide clear plans for credential rotation, secrets management, and post‑incident hardening.

Practical example: detection + quick cleanup script (use with caution)

Use this investigative PHP helper only in a controlled environment (staging/local). Back up before running any changes.

get_results( $wpdb->prepare(
    "SELECT meta_id, post_id, meta_key, meta_value FROM {$wpdb->postmeta} WHERE meta_value LIKE %s LIMIT 100",
    $pattern
) );

foreach ( $results as $row ) {
    echo "meta_id: {$row->meta_id} post_id: {$row->post_id} meta_key: {$row->meta_key}
";
    // Optionally inspect meta_value here
}
?>

After investigating, remove or sanitize only confirmed malicious values — never perform blind deletions.

Final checklist — immediate actions (TL;DR)

• Update Simple Download Monitor to >= 4.0.6 now.
• If you can’t update: deactivate the plugin, hide custom fields, or restrict Contributor capabilities.
• Audit Contributor accounts and recent changes.
• Search the DB for script tags and suspicious attributes; remove confirmed malicious values.
• Run a full malware scan and file integrity checks.
• Apply a temporary WAF rule to block script payloads targeting admin/REST endpoints.
• Rotate credentials for privileged users and any leaked secrets.

Conclusion

Stored XSS remains one of the most common and impactful web vulnerabilities because it enables persistent exploitation. Although this Simple Download Monitor issue requires Contributor access to insert payloads and commonly needs a victim to view the content, the practical risk is real — especially for sites with multiple user roles or loose editorial controls.

Fastest remediation: update the plugin to the patched version (4.0.6). Where immediate patching isn’t possible, combine temporary virtual patching, strict privilege management, database scanning, and output escaping. Use a layered approach: secure code, least privilege, monitoring, and appropriate operational protections.

From a Hong Kong security practicioner perspective: act promptly, document your steps, and treat any suspicious finds as a potential incident until proven clean.