If the plugin is present and you cannot immediately apply a vendor patch, prioritise defence-in-depth. The following practical sequence can be applied immediately.

1. Restrict admin access immediately
   • Limit the number of administrator accounts. Remove or downgrade accounts that do not need admin privileges.
   • Force password resets for all administrators and remove weak or reused passwords.
   • Enforce two-factor authentication (2FA) for administrator accounts.
2. Audit plugin settings and clean suspicious fields

   Inspect all settings belonging to the plugin. Remove content that contains script tags, inline event handlers (onload, onclick), or javascript: URIs. If suspicious values are found, consider restoring those specific settings from a known-clean backup created before the disclosure.

3. Put the site into maintenance or restricted mode for admins

   If active compromise is suspected, temporarily restrict admin access by limiting IP ranges or using access-control mechanisms to reduce who can reach plugin admin pages.

4. Uninstall or disable the plugin if possible

   If the plugin is not essential to site operation, disable it until a vendor patch is available. If it must remain active, restrict who can access the plugin’s admin pages (capability checks or IP restrictions).

5. Apply virtual patching at server or WAF level (if available)

   Use server-level filters or a Web Application Firewall to block obvious injection patterns and reduce the chance that stored payloads execute. Test rules carefully to avoid blocking legitimate administration traffic.

6. Strengthen Content Security Policy (CSP) and security headers

   Implement a CSP that reduces the risk of injected scripts executing (avoid 'unsafe-inline' where possible and use nonces for admin pages). Ensure headers such as X-Content-Type-Options, X-Frame-Options, and Referrer-Policy are configured.

7. Monitor and investigate

   Increase logging and monitoring for admin actions and unusual page renders. If a stored payload is found, isolate, document, and remove it. Consider taking the site offline for deeper forensic work if needed.

8. Clean-up and post-incident actions

   Rotate all credentials (admin accounts, FTP/SFTP, hosting control panel) that may have been exposed. Audit scheduled tasks, uploads folder, and any unknown PHP files. Restore from a known-clean backup if deeper compromise is suspected.

Developers should apply secure coding practices to avoid XSS and other injection flaws. If you maintain the plugin or can produce a temporary patch, follow these remediation steps.

1. Encode output, do not rely solely on input filtering

   Escape data at the point of output. Use WordPress escaping functions:

   • Use esc_html() when outputting HTML text into the page.
   • Use esc_attr() when outputting into HTML attributes.
   • Use wp_kses_post() or wp_kses() with an allowlist for controlled HTML.

   Never echo untrusted data directly.

2. Sanitize inputs using WordPress functions

   For text inputs use sanitize_text_field(). For rich HTML input use wp_kses() with an explicit allowed tags/attributes set. Validate and sanitize option values before saving with update_option().

3. Use capability checks and nonces in admin forms

   Verify that incoming requests are from authorised users and that the action is intended (check current_user_can() and wp_verify_nonce()).

4. Avoid storing unescaped HTML that will later be echoed directly

   If HTML must be stored, ensure consistent sanitisation on save and safe encoding on render.

5. Release a vendor patch and coordinate disclosure

   Provide a fixed plugin version that properly encodes output and sanitises inputs. Communicate upgrade instructions and manual clean-up steps to administrators.

Web Application Firewalls and server-level filters can reduce exploitation risk. Below are high-level, non-exploitable rule concepts you can implement in a WAF or via server filters (e.g., ModSecurity). Adapt and test thoroughly to avoid false positives.

1. Block obvious script tag insertions in admin inputs

   Reject or flag POST/PUT requests to plugin settings endpoints when input contains , onerror=, onload=, or javascript: URIs. Prefer whitelisting expected fields and strict sanitisation for free-text fields.

2. Block base64-encoded JavaScript and data: URIs

   Flag inputs containing data: URIs with embedded JavaScript or suspicious base64 patterns.

3. Block inline event attributes

   Create rules to neutralise or remove event attributes (onclick, onmouseover, onfocus, etc.) submitted to admin endpoints.

4. Sanitise outbound HTML on admin pages

   Use response filters to remove unexpected script tags on pages where they’re not expected (for example, plugin settings pages).

5. Monitor and rate-limit suspicious admin activity

   Rate-limit and alert on rapid changes to plugin options or content that contains HTML tags unusual for a given field. Alert when new admin users are created or when settings are updated with HTML content.

6. Conservative pseudo-rule example

   If the WAF supports pattern matching, a conservative approach is to challenge or block requests to /wp-admin/* where the body contains obvious script patterns, and to alert administrators. Fine-tune and test to avoid blocking legitimate traffic.