TL;DR — A stored Cross‑Site Scripting (XSS) vulnerability (CVE-2026-3604) affects the “WP SEO Structured Data Schema” plugin in versions up to and including 2.8.1. An authenticated user with Contributor privileges can store a malicious script that executes when a higher‑privileged user or another visitor views an affected page. The issue carries a CVSS-equivalent severity of 6.5 and requires user interaction for successful exploitation. No official patch was available at disclosure — apply mitigations immediately if you run this plugin.

為什麼這很重要（簡短）

存儲的 XSS 特別危險，因為惡意有效載荷被持久化（數據庫、選項、postmeta），並在任何查看受感染內容的人的瀏覽器中執行。貢獻者通常可以創建內容，但不被信任插入原始 HTML。如果這些用戶可以存儲後來呈現給管理員或編輯的腳本，則網站可以從低權限的妥協升級為完全控制：會話劫持、惡意管理員創建、配置修改、後門安裝、SEO 垃圾郵件或惡意內容的分發。.

漏洞快照

• 漏洞： 經過身份驗證的 (貢獻者+) 存儲跨站腳本 (XSS)
• 受影響的軟體： WP SEO 結構化數據架構插件
• 受影響版本： ≤ 2.8.1
• CVE： CVE-2026-3604
• 發布日期： 2026 年 5 月 11 日
• 所需權限： 貢獻者 (或更高)
• CVSS 類似的嚴重性： 6.5（中等/中等）
• 利用： 需要貢獻者帳戶的存在和特權用戶互動（例如，在管理後台或前端查看或與存儲的有效載荷互動）
• 披露時的修補狀態： 沒有官方修補程序可用（網站擁有者必須應用緩解措施）

存儲 XSS 在此上下文中的工作原理

Stored XSS occurs when user-supplied input is saved and later output without proper sanitization or escaping. In this plugin, certain fields Contributors can populate (structured data snippets, meta fields, or custom schema entries) are not sufficiently filtered. An attacker with a Contributor account can insert HTML/JavaScript payloads that are saved to the database. When an admin/editor or a visitor loads the page or the plugin’s admin view that outputs that content, the malicious script runs in the context of the user’s browser.

Because the script runs with the victim’s browser privileges, consequences include:

• 竊取身份驗證 Cookie 或會話令牌（導致帳戶接管）
• 通過偽造請求執行管理操作
• 安裝持久性後門、創建惡意管理員帳戶或修改插件/主題
• 更改 SEO 內容或插入垃圾鏈接以損害聲譽
• 提供惡意 JavaScript，將訪客重定向或加載隨機下載的惡意軟件

雖然攻擊者最初可能只有一個貢獻者帳戶，但存儲的 XSS 一旦與更高權限的用戶互動，就可能升級為完全妥協。.

誰面臨風險？

• 安裝並啟用 WP SEO 結構化數據架構插件的網站，運行版本 2.8.1 或更舊版本
• 允許外部用戶註冊或以其他方式獲得貢獻者（或更高）角色的網站
• 多作者博客，其中貢獻者提供結構化數據或填寫插件管理的字段，這些字段後來在管理界面或前端模板中呈現
• 管理員或編輯經常在管理界面直接審查內容而不進行額外清理的網站

If you don’t use the plugin or it’s not active, you are not impacted. If you host the plugin but haven’t updated or removed it, treat this as a high-priority assessment.

實際利用場景

1. 貢獻者 → 社會工程 → 管理員

   An attacker with a Contributor account saves a crafted schema snippet or meta field containing a hidden script. An editor/admin opens the plugin’s settings page or views the post in the admin preview; the script executes and uses the admin’s authenticated cookies to call admin-only AJAX endpoints (create admin accounts, install plugins, change site email, etc.).

2. 貢獻者 → 前端執行 → 訪客

   If the plugin outputs structured data or schema markup into the front-end without escaping, a visitor’s browser can execute the payload. The script can load third-party malicious code or leverage browser flaws to harm visitors and the site’s reputation.

3. 存儲的有效載荷 + 定時任務

   當特權用戶訪問 cron 或維護頁面時，有效載荷可以觸發操作，自動化持久性並使清理變得更加困難。.

立即採取的步驟（在 24 小時內）

1. 清點和評估
   • 檢查 WP SEO 結構化數據架構插件是否已安裝並確定其版本。.
   • WP-CLI： wp 插件獲取 wp-seo-structured-data-schema --field=version
   • WordPress 管理員：插件 → 已安裝插件 → 檢查版本
   • 如果插件處於活動狀態且版本 ≤ 2.8.1，請立即採取緩解措施。.
2. 如果您無法修補（沒有官方修補程序可用）
   • 如果可行，立即停用插件。停用是最安全的立即緩解措施。.
   • WP-CLI： wp 插件停用 wp-seo-structured-data-schema
   • 如果因業務原因無法停用，則限制暴露：
     • 通過 IP 限制對插件管理頁面的訪問（使用主機控制或伺服器配置）。.
     • 暫時禁用貢獻者創建或編輯插件管理的字段的能力。.
     • 在內容上線之前，要求編輯進行手動審核。.
3. 鎖定用戶權限
   • 刪除或降級任何不受信任的貢獻者帳戶。.
   • 強制使用強密碼並定期更換管理員和編輯的憑證。.
   • 如果不需要，則禁用新用戶註冊。.
4. 檢查和清理
   • 在內容和插件相關存儲中搜索可疑腳本和注入標籤（見檢測部分）。.
   • 刪除發現的惡意腳本、流氓用戶或注入的管理帳戶。.
   • 如果文件完整性受到影響，則從乾淨的備份中恢復。.
5. 監控日誌和流量
   • 檢查伺服器和應用程序日誌以查找可疑的 POST 請求、不尋常的管理頁面查看或活動激增。.
   • 監控外發流量，尋找可能表明惡意軟件正在發送信號的未知主機連接。.
6. 應用 WAF/虛擬修補（如果可用）

   部署 Web 應用防火牆規則以阻止受影響插件端點中的典型 XSS 負載。阻止明顯的腳本標籤和可疑屬性提交到與架構相關的端點，並監控/阻止來自貢獻者端點的惡意 POST。.

7. 計劃修復

   監視官方插件渠道以獲取安全更新。當修補程序發布時，立即在測試環境中應用，測試後再推送到生產環境。.

檢測：如何查找可能的利用工件

假設攻擊者將腳本存儲在帖子內容、帖子元數據、選項或自定義表中。使用這些方法來定位可疑工件。.

在內容中搜尋腳本標籤或事件屬性

WP-CLI 範例：

wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%';"
wp db query "SELECT meta_id, meta_key FROM wp_postmeta WHERE meta_value LIKE '%<script%';"

Direct SQL (replace table prefixes if different):

SELECT ID, post_title FROM wp_posts WHERE post_content REGEXP '<[[:space:]]*script';
SELECT post_id, meta_key FROM wp_postmeta WHERE meta_value REGEXP '<[[:space:]]*script';

Look for suspicious HTML attributes commonly used in XSS payloads: onerror=, onload=, onclick=, javascript:, document.cookie, window.location, eval(.

Search site options and plugin-related fields

SELECT option_name FROM wp_options WHERE option_value LIKE '%<script%';

Search files and uploads

• Scan the files directory for recently added PHP files or suspicious JS files.
• Use grep to find injected strings:

  grep -R --exclude-dir=uploads 'document.cookie' .
  grep -R --exclude-dir=wp-content/uploads '<script' wp-content/plugins/

檢查用戶帳戶

List accounts with Contributor+ privileges and their last login times:

wp user list --role=contributor --fields=ID,user_login,user_email,user_registered,last_login

注意： last_login may require a plugin that records logins; otherwise check authentication logs on the server.

If you find injected content, take screenshots, export the records, and store them for forensic analysis before cleaning.

事件響應檢查清單（詳細）

1. 隔離
   • Deactivate the vulnerable plugin immediately or restrict access to its admin pages.
   • If you suspect active compromise, consider taking the site into maintenance mode and blocking public access temporarily.
2. 保留
   • Make a full backup (database + files) and preserve a copy offline for forensic purposes.
3. 識別
   • Run the detection queries above.
   • Look for new admin users, unauthorized plugins, modified core files, or unexpected scheduled tasks (wp_cron).
4. 移除
   • Delete injected scripts from posts/postmeta/options.
   • Remove rogue users and reset passwords for editors and admins.
   • Remove any unauthorized plugins or themes and revert modified files from a trusted backup.
5. 恢復
   • Restore core files and plugin files from known-good sources.
   • Apply any available security update for the plugin when released. If no official patch yet, continue virtual patching and other mitigations.
6. 審查和加固
   • Audit user roles and permissions.
   • Ensure two-factor authentication (2FA) for all admins and editors.
   • Review logging and monitoring practices to catch future abuse earlier.
   • Implement a content-review workflow: contributors should not publish content that bypasses editor review.
7. 通知
   • Inform affected stakeholders (site owners, administrators).
   • If customer data was exposed or site integrity was affected, follow applicable regulatory obligations.
8. 事後分析。
   • Document root cause, steps taken, and improvements to prevent recurrence.

Mitigation strategies — technical guidance for developers and site admins

Practical defensive steps to mitigate the vulnerability and reduce future risk.

1. 最小權限原則
   • Limit user capabilities. Contributors should not be able to inject raw HTML or scripts.
   • Consider a custom role with stricter capabilities where appropriate.
2. 清理輸入並轉義輸出
   • Sanitize on input and escape on output using WordPress APIs:
   • 在輸入時進行清理： wp_kses_post(), sanitize_text_field(), wp_strip_all_tags()
   • 輸出時進行轉義： esc_html(), esc_attr(), wp_kses_post()
3. 4. 內容安全政策 (CSP)

   Apply CSP headers to limit the risk of script execution from unauthorized sources. Example (start restrictive, then adjust):

   Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'nonce-<random>'; object-src 'none';

   CSP reduces XSS impact but must be implemented carefully to avoid breaking functionality.

4. Disable unfiltered HTML for untrusted roles

   確保貢獻者沒有 unfiltered_html capability. Use capability management code or plugins to remove it. Example (add to an mu-plugin or functions.php with caution):

   <?php
   // mu-plugin/remove-unfiltered-html.php
   function hk_remove_unfiltered_html_from_contributors() {
     $role = get_role('contributor');
     if ( $role && $role->has_cap('unfiltered_html') ) {
       $role->remove_cap('unfiltered_html');
     }
   }
   add_action('init', 'hk_remove_unfiltered_html_from_contributors');

5. Harden REST API and AJAX endpoints

   Ensure endpoints that accept structured data check capabilities and nonces. Limit who can POST to endpoints that manage schema or plugin settings.

6. 使用 WAF 進行虛擬修補

   If you operate or can configure a Web Application Firewall, add rules that inspect POST data for XSS payloads on plugin-specific endpoints. Example generic patterns to block:

   • 阻止帶有 <script in parameters destined to schema endpoints.
   • 阻止 onerror=, onload=, javascript: appearing in form fields.
7. Input validation layers

   When structured data is expected (e.g., JSON-LD), validate that incoming strings match expected JSON formats and allowed keys. Reject or sanitize unexpected HTML and attributes.

8. Review plugin updates and vendor communications

   Subscribe to vendor security announcements and update promptly when a fix is released.

Practical mitigation examples (do‑it‑yourself)

Concrete actions administrators can apply immediately.

1. Deactivate plugin

   wp 插件停用 wp-seo-structured-data-schema (if deactivation is acceptable)

2. Temporarily prevent Contributors from submitting posts

   Use a role-management approach to change Contributor capabilities or require content moderation.

3. Add a simple server-side filter (example mu-plugin)

   This example strips <script> tags from 文章內容 on save. Use as a short-term defensive measure and test thoroughly:

   <?php
   // mu-plugin/strip-scripts-on-save.php
   add_filter('content_save_pre', 'hk_strip_scripts_on_save', 10, 1);
   function hk_strip_scripts_on_save($content) {
       if ( current_user_can('contributor') || current_user_can('author') ) {
           // Remove script tags
           $content = preg_replace('#<script(.*?)>(.*?)</script>#is', '', $content);
       }
       return $content;
   }

   注意：這是一個防禦性臨時措施。插件代碼中的正確修復是適當的清理。.

4. 在網頁伺服器層級阻止提交

   添加請求主體檢查規則，拒絕包含 <script in form data to plugin endpoints. Consult your hosting provider or server administrator for implementation details.

Long-term hardening — lessons learned

• Treat any content re-rendered in admin screens with the same caution as front-end content — admins are high-value targets.
• Limit users who can create content without review. Enforce editor review for content with structured data or raw markup.
• Use layered defenses: secure code, WAF protections, monitoring, and recovery planning.
• Maintain up-to-date backups with regular verification and offsite copies.
• Deploy 2FA and enforce strong passwords for all privileged accounts.

Detection queries and forensics cheat sheet

• 列出插件版本：

  wp 插件獲取 wp-seo-structured-data-schema --field=version

• Find posts containing <script:

  wp db 查詢 "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%';"

• 查找包含腳本的 postmeta：

  wp db query "SELECT meta_id, post_id, meta_key FROM wp_postmeta WHERE meta_value LIKE '%<script%';"

• 搜索選項：

  wp db query "SELECT option_name FROM wp_options WHERE option_value LIKE '%<script%';"

• List contributor accounts:

  wp 使用者列表 --role=contributor --fields=ID,user_login,user_email,user_registered

• Check current active plugins:

  wp 插件列表 --status=active

Always make a copy of affected rows before cleaning to preserve evidence.

What if you already see signs of compromise?

If you detect unexpected admin accounts, changed content, unknown scheduled events, or file system changes:

1. Immediately change all administrative credentials and rotate application secrets (API keys, OAuth tokens, etc.).
2. Put the site in maintenance/offline mode to prevent further harm.
3. Restore from a clean backup prior to the compromise, after ensuring the backup is not infected.
4. Engage a security professional if you’re unable to determine root cause or if the attacker maintains persistence.

最終建議——優先行動

1. 清單： Determine whether the vulnerable plugin is installed and active — do this now.
2. Deactivate or restrict: If installed and vulnerable, deactivate the plugin or restrict access to its pages and endpoints.
3. Lockdown accounts: Remove untrusted Contributor accounts and force password resets for privileged users.
4. 掃描並清理： Inspect posts/postmeta/options and remove any injected scripts.
5. WAF/virtual patch: If available, deploy WAF rules to block known XSS patterns for plugin endpoints.
6. Monitor and recover: Keep heightened monitoring and restore clean backups where necessary.
7. 當可用時進行修補： Apply the official plugin update immediately when released and test before reactivating.

資源和參考

• CVE 參考
• Researcher credit: Muhammad Yudha – DJ (disclosure credited to the researcher in the public advisory)