概述

在 2026 年 6 月 1 日，影響 Word Replacer WordPress 插件（版本 ≤ 0.4）的儲存型跨站腳本漏洞被公開披露並分配了 CVE-2026-3620。該問題是一個認證的僅限管理員的儲存型 XSS——這意味著擁有 WordPress 管理員權限的用戶可以保存惡意輸入，該輸入在未經適當轉義的情況下被渲染，導致 JavaScript 在網站訪問者或其他管理用戶的瀏覽器中執行。.

雖然這個漏洞需要管理員訪問來引入有效載荷，但後果可能是嚴重的：持久的帳戶接管、網站篡改、後門安裝、cookie/令牌盜竊、權限提升和網站內的橫向移動。報告的 CVSS 基本分數為 5.9（中等），但實際風險在很大程度上取決於攻擊者是否能獲得或強迫管理員帳戶（社會工程學、重複使用的密碼、受損的設備、流氓承包商等）。.

本指南總結了漏洞的工作原理、現實攻擊場景、檢測指標、遏制和緩解步驟（包括臨時修復）、長期加固以及開發者修復根本原因的指導。.

來源：漏洞在公共通告中披露（CVE-2026-3620）。研究歸功於 san6051（COFFSec）。.

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

儲存型跨站腳本（XSS）發生在攻擊者將惡意腳本儲存在伺服器端數據（數據庫、選項表、帖子、插件設置等）中，該腳本隨後在未經適當轉義或清理的情況下傳遞給其他用戶。由於有效載荷是持久的，隨著時間的推移，許多訪問者和用戶可能會受到影響。.

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:

• 管理員帳戶經常成為釣魚、憑證填充和社會工程學的目標。.
• 管理員可以創建內容和持久的網站數據。.
• 攻擊者可以強迫管理員粘貼或導入有效載荷，或使用受損的管理員直接注入惡意條目。.
• 在管理儀表板中呈現的儲存型 XSS 可以立即危害其他管理會話。.

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

Word Replacer 漏洞的工作原理（高層次）

核心技術問題很簡單：

1. 該插件為管理員提供了一個用於定義儲存在數據庫中的替換規則的 UI。.
2. 當這些設置被保存時，該插件未能正確清理或驗證替換內容。.
3. 當插件在前端或管理儀表板上呈現這些儲存的值時，它將內容輸出為 HTML 而不進行轉義，允許嵌入的 JavaScript 執行。.
4. 該腳本以網站來源運行，使得行為如同受害者訪客或管理員。.

典型的不安全模式包括：

• 儲存原始 HTML 或未轉義的文本並直接回顯（例如，echo $value;）而不是使用 esc_html()、esc_attr() 或 wp_kses()。.
• 建立插入頁面 HTML 或屬性的替換字串而未進行適當的轉義。.
• 允許事件處理程序或 javascript: URI 作為條目的一部分被儲存。.

現實攻擊場景

• 騙局管理員帳戶： 控制管理員帳戶的攻擊者安裝替換條目，將 JavaScript 注入頁面和儀表板，從而能夠創建新的管理員、編輯主題或濫用 REST API。.
• 通過釣魚/憑證重用而妥協的管理員： 攻擊者欺騙管理員粘貼或儲存攻擊者提供的替換條目或點擊包含有效負載的導入 URL。.
• 第三方濫用： 擁有管理訪問權限的承包商或機構引入未轉義的內容。.
• 目標轉移： 儲存的 XSS 在管理儀表板中執行並竊取身份驗證令牌或隨機數，從而啟用進一步的行動。.

雖然僅通過此漏洞無法實現遠程未經身份驗證的接管，但社會工程學和針對性妥協經常彌補這一差距。.

影響和典型攻擊者目標

一旦儲存的 XSS 執行，攻擊者通常旨在：

• 竊取會話令牌並接管帳戶。.
• 創建新的管理員用戶或提升權限。.
• 安裝持久後門（惡意插件、修改過的主題、PHP 上傳）。.
• 將訪客重定向到詐騙或隨機下載。.
• 顯示欺詐內容或注入貨幣化代碼。.
• 從表單、評論或電子商務頁面中收集客戶數據。.
• 如果憑證存在於管理 UI 中，則轉移到主機面板或 API。.

CVE 和嚴重性上下文

• CVE 識別碼： CVE-2026-3620
• 受影響版本： Word Replacer 插件 ≤ 0.4
• 類型： 儲存的跨站腳本攻擊（XSS）
• 所需權限： 管理員
• 補丁狀態（在披露時）： 沒有可用的官方插件補丁
• CVSS 基本： 5.9
• 研究信用： 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.

偵測 — 妥協指標

主要偵測技術：

1. 在數據庫中搜索可疑的替換規則或條目：

   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. 監控外發連接： 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. 停用或移除插件： 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. 備份： 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. 溝通： For e-commerce or membership sites, be ready to notify stakeholders if user data may have been exposed.

通過 WAF 或伺服器規則進行虛擬修補

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 );

注意：

• 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

• 最小權限原則： 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.
• 強制執行 MFA： 要求所有管理帳戶使用多因素身份驗證。.
• 強密碼： 使用獨特且強大的密碼和密碼管理器。.
• 禁用文件編輯： 添加到 9. 或使用使會話失效的插件。在可行的情況下強制執行雙因素身份驗證。: define( 'DISALLOW_FILE_EDIT', true );
• 保持軟體更新： Update WordPress core, themes and plugins; remove unused components.
• Limit plugins: Install plugins from reputable sources and review code for unusual behaviour when possible.
• 定期掃描： Run vulnerability and malware scans and monitor logs for unusual admin activity.
• 備份： 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_text_field() 或 sanitize_textarea_field() for plain text. For limited HTML, use wp_kses() 嚴格的白名單。.
2. 在渲染時轉義輸出： Always escape at the point of output: esc_html(), esc_attr(), esc_url() 或 wp_kses_post() 根據需要。.
3. 能力和隨機數檢查： Verify user capabilities and nonces before processing POSTs.
4. 避免儲存原始 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. 自動化測試： 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.

對於主機和管理的 WordPress 提供商

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 或 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. 保留日誌和備份以供取證分析。.
7. Monitor traffic and admin logs closely for at least two weeks after remediation.