Overview

On 1 June 2026 a stored Cross-Site Scripting vulnerability affecting the Word Replacer WordPress plugin (versions ≤ 0.4) was publicly disclosed and assigned CVE-2026-3620. The issue is an authenticated, administrator-only stored XSS — meaning a user with Administrator privileges in WordPress can save malicious input that is later rendered without proper escaping, causing JavaScript to execute in the browser of site visitors or other administrative users.

Although this vulnerability requires Administrator access to introduce the payload, the consequences can be severe: persistent account takeover, site defacement, backdoor installation, cookie/token theft, privilege escalation and lateral movement inside the site. The reported CVSS base score is 5.9 (medium), but practical risk depends heavily on whether an attacker can acquire or coerce an Administrator account (social engineering, reused passwords, compromised devices, rogue contractor, etc.).

This guidance summarises how the vulnerability works, realistic attack scenarios, detection indicators, containment and mitigation steps (including temporary fixes), longer-term hardening, and developer guidance to fix the root cause.

Credit: vulnerability disclosed in public advisory (CVE-2026-3620). Research credited to san6051 (COFFSec).

What is Stored XSS and why is an “authenticated admin” vector important?

Stored Cross-Site Scripting (XSS) occurs when an attacker stores a malicious script in server-side data (database, options table, posts, plugin settings, etc.) and that script is later delivered to other users without proper escaping or sanitization. Because the payload is persistent, many visitors and users can be affected over time.

An “authenticated administrator” qualifier means only accounts with Administrator capabilities can save the malicious payload. That reduces the immediate attack surface compared to unauthenticated bugs, but it remains dangerous because:

• Administrator accounts are frequent targets via phishing, credential stuffing and social engineering.
• Administrators can create content and persistent site data.
• An attacker can coerce an Administrator to paste or import payloads, or use a compromised admin to directly inject malicious entries.
• Stored XSS that renders in the admin dashboard can immediately compromise other administrative sessions.

Even “admin-only” stored XSS can lead to full site compromise when combined with real-world attacker techniques.

How the Word Replacer vulnerability works (high-level)

The core technical issue is straightforward:

1. The plugin exposes a UI for administrators to define replacement rules that are stored in the database.
2. When those settings are saved, the plugin fails to properly sanitize or validate the replacement content.
3. When the plugin renders those stored values on the front-end or in the admin dashboard, it outputs the content into HTML without escaping, allowing embedded JavaScript to execute.
4. The script runs with the site origin, enabling actions as the victim visitor or administrator.

Typical unsafe patterns include:

• Storing raw HTML or unescaped text and echoing it directly (e.g., echo $value;) instead of using esc_html(), esc_attr() or wp_kses().
• Building replacement strings that are inserted into page HTML or attributes without proper escaping.
• Allowing event handlers or javascript: URIs to be saved as part of entries.

Realistic attack scenarios

• Rogue administrator account: An attacker controlling an admin account installs replacement entries that inject JavaScript into pages and dashboards, enabling creation of new admins, theme edits, or REST API abuse.
• Compromised admin via phishing/credential reuse: An attacker tricks an Administrator into pasting or saving attacker-supplied replacement entries or clicking an import URL containing payloads.
• Third-party misuse: A contractor or agency with admin access introduces unescaped content.
• Targeted pivot: Stored XSS executes in the admin dashboard and steals authentication tokens or nonces, enabling further actions.

Although remote unauthenticated takeover is not available through this bug alone, social engineering and targeted compromise frequently bridge that gap.

Impact and typical attacker goals

Once the stored XSS executes, attackers commonly aim to:

• Steal session tokens and take over accounts.
• Create new Administrator users or elevate privileges.
• Install persistent backdoors (malicious plugins, modified themes, PHP uploads).
• Redirect visitors to scams or drive-by downloads.
• Display fraudulent content or inject monetisation code.
• Harvest customer data from forms, comments, or e-commerce pages.
• Pivot to hosting panels or APIs if credentials are present in the admin UI.

CVE and severity context

• CVE identifier: CVE-2026-3620
• Affected versions: Word Replacer plugin ≤ 0.4
• Type: Stored Cross-Site Scripting (XSS)
• Required privilege: Administrator
• Patch status (at disclosure): No official plugin patch available
• CVSS base: 5.9
• Research credit: san6051 (COFFSec)

Even with a “medium” CVSS, treat this vulnerability as urgent for sites where admin accounts are at risk or where administrators accept input from third parties.

Detection — indicators of compromise

Key detection techniques:

1. Search the database for suspicious replacement rules or entries:

   Look for HTML tags (<script>, <iframe>) or event attributes (onclick, onmouseover) stored in options or post meta.

   Example SQL queries:

   SELECT option_name, option_value
   FROM wp_options
   WHERE option_name LIKE '%word_replac%' OR option_name LIKE '%word_replacer%';
   
   SELECT * FROM wp_postmeta WHERE meta_value LIKE '%<script%';
   
   SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%';

   Inspect for encoded payloads (base64), “javascript:” URIs, eval(, document.cookie, XMLHttpRequest, fetch(.

2. Scan front-end pages: Crawl public pages and grep for unexpected inline <script> tags or event handlers not originating from known plugins/themes.
3. Audit admin pages and user lists: Check for new admin users and recent changes to plugin/theme files.
4. Server and application logs: Look for POSTs to admin pages or import endpoints, unusual user agents, or source IPs.
5. Malware scanners: Use WordPress-aware scanners to find injected JS or common patterns.
6. Monitor outbound connections: Unexpected outbound HTTPS requests after suspicious entries were added can indicate live exploitation.

Immediate containment & triage (what to do now)

If your site uses the vulnerable Word Replacer plugin (≤ 0.4), act immediately:

1. Isolate admin accounts: Force password reset for all Administrators and enable or enforce MFA.
2. Deactivate or remove the plugin: If safe to do so, deactivate and delete Word Replacer until a patched release is available.
3. Scan for malicious stored content: Search options/postmeta for <script>, javascript:, on* attributes and remove or sanitize suspicious entries. Export data first for forensic preservation if needed.
4. Inspect users and files: Remove unknown admin accounts; compare plugin/theme files against clean copies.
5. Backups: Take a full backup (files + DB) immediately for forensic preservation, then create a clean restore point.
6. Logs and forensics: Preserve webserver and PHP logs around the window of possible compromise.
7. Communicate: For e-commerce or membership sites, be ready to notify stakeholders if user data may have been exposed.

Virtual patching via WAF or server rules

If you cannot remove the plugin immediately, virtual patching through a Web Application Firewall (WAF) or server-level rules is an effective temporary mitigation. Operators can deploy rules to:

• Block admin POST submissions that contain <script>, “javascript:” URIs, or inline event handlers in fields associated with the plugin.
• Restrict access to the plugin admin page to trusted IP ranges.
• Sanitize or strip dangerous input patterns on the fly.

Example ModSecurity-style rule (illustrative — test in staging):

SecRule REQUEST_METHOD "@streq POST" "phase:2,chain,deny,id:1003001,log,msg:'Block possible Word Replacer stored XSS payload'"
  SecRule ARGS|ARGS_NAMES "@rx (<script|javascript:|on\w+\s*=|document\.cookie|window\.location)" "t:none,t:urlDecodeUni,log"

Nginx example — block POSTs to a plugin admin page (adjust path & IP list):

location ~* /wp-admin/admin\.php$ {
  if ($request_method = POST) {
    if ($arg_page = "word-replacer") {
      allow 203.0.113.45;   # trusted admin IP
      deny all;
    }
  }
}

Warning: IP-based restrictions can lock out legitimate administrators using dynamic IPs. Test rules in staging before applying to production.

Quick temporary WordPress-level mitigation (mu-plugin)

If you can add a must-use plugin (mu-plugin), you can intercept option updates and sanitize content that looks like it belongs to Word Replacer. Place the file in wp-content/mu-plugins/block-word-replacer-xss.php.

<?php
/**
 * MU plugin: sanitize Word Replacer option updates to remove inline scripts and event handlers.
 * Install: save as wp-content/mu-plugins/block-word-replacer-xss.php
 */

add_filter( 'pre_update_option', function( $new_value, $old_value, $option_name ) {
    if ( strpos( $option_name, 'word_replacer' ) !== false || strpos( $option_name, 'word-replacer' ) !== false ) {
        // Use wp_kses to allow only safe tags and attributes. Adjust allowed tags as needed.
        $allowed = array(
            'a'      => array( 'href' => true, 'title' => true, 'rel' => true ),
            'br'     => array(),
            'em'     => array(),
            'strong' => array(),
            'b'      => array(),
            'i'      => array(),
            'u'      => array(),
            'p'      => array(),
            'ul'     => array(),
            'ol'     => array(),
            'li'     => array(),
        );
        if ( is_string( $new_value ) ) {
            $new_value = wp_kses( $new_value, $allowed );
        }
    }
    return $new_value;
}, 10, 3 );

Notes:

• This is a protective stopgap to strip inline JavaScript and unsafe attributes from options matching the plugin. It is not a permanent fix.
• Do not rely on this alone — the plugin code should be fixed at source.

Nginx / Apache blocking for plugin admin UI

If the plugin admin page slug is known (for example: admin.php?page=word-replacer), block direct access by non-trusted IPs at the webserver level.

Nginx example (deny all POSTs to the plugin settings page except specific IPs):

location ~* /wp-admin/admin\.php$ {
  if ( $arg_page = "word-replacer" ) {
    if ( $request_method = POST ) {
      allow 203.0.113.45;  # admin office IP
      deny all;
    }
  }
}

Apache .htaccess example (inside /wp-admin):

<If "%{QUERY_STRING} =~ /page=word-replacer/ && %{REQUEST_METHOD} == 'POST'">
  Require ip 203.0.113.45
</If>

Test carefully — these rules can block legitimate admin activity.

Recovery and clean-up checklist after a confirmed compromise

1. Take the site offline or enable maintenance mode if public traffic is being poisoned.
2. Preserve logs and a forensic backup (full files + DB).
3. Reset credentials for all admin accounts and users with elevated privileges; enforce MFA.
4. Remove malicious replacement entries from the database.
5. Scan and clean the filesystem for injected files or backdoors. Replace modified core, theme and plugin files with fresh copies from trusted sources.
6. Remove unknown plugins/themes and reinstall only from official sources.
7. Rotate API keys, tokens, and any credentials exposed to the admin interface.
8. Restore from a clean backup if infection is widespread and cleanup is not feasible.
9. Re-enable public access only after multiple confirmation scans return clean results.
10. Conduct a post-incident audit to identify how the admin account was compromised (phishing, weak MFA, password reuse) and remediate the root cause.

If you are not confident performing the recovery, engage a professional incident response provider.

Long-term mitigation & best practices

• Principle of Least Privilege: Do not use Administrator accounts for everyday tasks; create Editor-level accounts for content editors.
• Minimal admin exposure: Keep the number of admin accounts minimal and review them regularly.
• Enforce MFA: Require multi-factor authentication for all admin accounts.
• Strong passwords: Use unique, strong passwords and a password manager.
• Disable file editing: Add to wp-config.php: define( 'DISALLOW_FILE_EDIT', true );
• Keep software up to date: Update WordPress core, themes and plugins; remove unused components.
• Limit plugins: Install plugins from reputable sources and review code for unusual behaviour when possible.
• Regular scanning: Run vulnerability and malware scans and monitor logs for unusual admin activity.
• Backups: Maintain automatic backups with offsite copies and periodic restore testing.
• Environment hardening: Use supported PHP versions, correct file permissions, secure hosting and HTTPS everywhere.
• WAF for virtual patching: Use a WAF to apply central rules that can block common exploit payloads while awaiting official plugin patches.

Developer guidance — how to fix this class of bugs properly

Plugin developers should follow these practices to prevent stored XSS:

1. Sanitize input on save: Use sanitize_text_field() or sanitize_textarea_field() for plain text. For limited HTML, use wp_kses() with a strict whitelist.
2. Escape output on render: Always escape at the point of output: esc_html(), esc_attr(), esc_url() or wp_kses_post() as appropriate.
3. Capability and nonce checks: Verify user capabilities and nonces before processing POSTs.
4. Avoid storing raw HTML: Avoid storing HTML that will later be embedded in attributes or inline scripts.
5. Minimise dynamic JavaScript: Avoid eval() and dynamic JavaScript construction from user content.
6. Document formats and safe defaults: Ensure safe default states for stored values and document expected formats.
7. Automated tests: Add tests to assert that inputs containing <script> are sanitized/escaped before output.
8. Secure upgrades: Provide clear upgrade paths and changelogs when sanitisation changes stored data formats.

For hosts and managed WordPress providers

Hosting providers can mitigate exposure by:

• Scanning client sites for the vulnerable plugin and notifying customers promptly.
• Temporarily blocking the plugin admin page at the platform level until customers remediate.
• Offering a one-click virtual patch that blocks requests attempting to save script tags to plugin options.
• Assisting customers with forced password resets and enabling MFA.
• Quarantining sites showing active signs of compromise and offering cleanup support where permitted.

Indicators to search for in monitoring and logs

• POST requests to admin pages containing: “<script”, “javascript:”, “onmouseover=”, “onload=”, “document.cookie”, “fetch(“, “XMLHttpRequest(“.
• Unexpected new Administrator accounts.
• File change events in wp-content/plugins or wp-content/themes shortly after suspicious admin POSTs.
• Outbound connections to unknown domains originating from the webserver.

Recommended immediate action plan — step by step

1. If the plugin is installed and can be removed safely, deactivate and delete Word Replacer (preferred).
2. If removal is not possible, apply a virtual patch via your WAF or server rules that block suspicious admin POSTs.
3. Force-reset admin passwords and enable MFA.
4. Audit the database for suspicious replacement entries and sanitize or remove them.
5. Scan and clean the site with a WordPress-aware malware scanner and perform file integrity checks.
6. Preserve logs and backups for forensic analysis.
7. Monitor traffic and admin logs closely for at least two weeks after remediation.