摘要

本報告提供了一個關鍵的未經驗證敏感資訊暴露與權限提升漏洞（CVE-2025-11749）的詳細技術分析，該漏洞發現於 AI Engine WordPress 插件中，影響版本包括 3.1.3 及之前的所有版本。此漏洞的核心源自於註冊 REST API 端點時的不安全設定，特別是省略了 'show_in_index' => false 參數。此疏忽透過標準的 WordPress REST API 索引公開暴露了插件的 Model Context Protocol (MCP) bearer token，允許未經驗證的攻擊者提取該 token，並隨後執行特權指令，例如修改使用者角色，導致網站完全被入侵。本分析聚焦於有漏洞的程式碼結構、攻擊機制，以及廠商實施的最小但有效的更新程式。

一個被遺忘的參數：為什麼 AI Engine 外掛會將您的金鑰主動送給陌生人？ | 資訊安全新聞

1. 簡介

將人工智慧（AI）功能整合到內容管理系統中已變得越來越普遍，像 AI Engine 這樣的 WordPress 插件提供了智慧聊天機器人和內容生成等功能。然而，引入複雜的客製化 API 端點以支援這些功能時，可能會無意中引入重大的安全風險。最近在 AI Engine 插件中發現了一個關鍵漏洞，追蹤為 CVE-2025-11749，對超過 100,000 個有效安裝構成了嚴重威脅 [1]。此缺陷被歸類為未經驗證的敏感資訊暴露，直接導致權限提升，其 CVSS 評分為關鍵的 9.8 分 [1]。此漏洞的技術根本原因在於 WordPress REST API 路由註冊過程中的設定錯誤，該錯誤將敏感的 bearer token 暴露給公眾。

2. 漏洞機制與技術分析

AI Engine 插件使用 Model Context Protocol (MCP) 來管理與各種 AI 代理的互動。該協議依賴一個秘密的 "Bearer Token" 來進行身份驗證和授權以執行指令，包括那些可以修改使用者權限的指令，例如 wp_update_user [1]。此漏洞根源於插件在 Meow_MWAI_Labs_MCP 類別中實作客製化 REST API 端點的方式，特別是在 rest_api_init() 函數內。

2.1. 不安全的 REST API 端點註冊

WordPress REST API 框架允許開發人員使用 register_rest_route() 函數來註冊客製化路由。此函數的一個關鍵參數是 'show_in_index' ，它控制該端點是否列在公開的 /wp-json/ REST API 索引中。預設情況下，此參數設定為 true 。AI Engine 插件引入了「No-Auth URL endpoints」，旨在用於特定 use cases，其中 bearer token 直接嵌入在 URL 路徑中。關鍵在於，這些端點在註冊時沒有明確地將 'show_in_index' 設定為 false [1]。

以下程式碼片段說明了受影響版本（最高至 3.1.3）中「No-Auth URL endpoints」的有漏洞註冊邏輯。token 被包含在路由中，但路由本身卻被公開索引： 

  1. // Vulnerable Code Snippet from AI Engine <= 3.1.3
  2. // No-Auth URL endpoints (with token in path)
  3. $noauth_enabled = $this->core->get_option( 'mcp_noauth_url' );
  4. if ( $noauth_enabled && !empty( $this->bearer_token ) ) {
  5.     // Endpoint for Server-Sent Events (SSE)
  6.     register_rest_route( $this->namespace, '/' . $this->bearer_token . '/sse', [
  7.         'methods' => 'GET',
  8.         'callback' => [ $this, 'handle_sse' ],
  9.         'permission_callback' => function ( $request ) {
  10.             return $this->handle_noauth_access( $request );
  11.         },
  12.         // 'show_in_index' is implicitly true here, exposing the route
  13.     ] );
  15.     // ... other vulnerable route registrations (POST /sse, POST /message)
  16. }

2.2. 攻擊流程

此漏洞的攻擊是一個兩階段的過程，如下方的架構圖所示。第一步涉及敏感資訊暴露，第二步涉及權限提升。

graph TD A[Unauthenticated Attacker] -->|1. Request /wp-json/| B(WordPress REST API Index); B -->|2. Returns JSON with Exposed Endpoint| C{Endpoint: /mcp/v1/<BEARER_TOKEN>/sse}; C -->|3. Extract BEARER_TOKEN| D[Attacker Possesses Valid Token]; D -->|4. Authenticated Request to MCP Endpoint| E(AI Engine MCP Endpoint); E -->|5. Execute wp_update_user Command| F[Privilege Escalation to Administrator]; F --> G[Full Site Compromise]; style A fill:#f9f,stroke:#333,stroke-width:2px style F fill:#f99,stroke:#333,stroke-width:2px style G fill:#f66,stroke:#333,stroke-width:4px click A "https://www.wordfence.com/blog/2025/11/100000-wordpress-sites-affected-by-privilege-escalation-vulnerability-in-ai-engine-wordpress-plugin/" "Source Article" click G "https://www.wordfence.com/blog/2025/11/100000-wordpress-sites-affected-by-privilege-escalation-vulnerability-in-ai-engine-wordpress-plugin/" "Source Article"

圖 1: CVE-2025-11749 攻擊流程

未經驗證的攻擊者只需向 WordPress REST API 索引端點（ /wp-json/ ）發送 GET 請求。回應主體是一個列出所有已註冊路由的 JSON 物件，其中將包含有漏洞端點的完整路徑，包括嵌入的 bearer token。這個原本應作為 MCP 秘密金鑰的 token，因此被公開暴露 [1]。

一旦攻擊者獲取了 bearer token，他們就可以使用它來驗證其對 MCP 端點的請求。MCP 被設計為接受各種指令，包括那些與 WordPress 核心功能互動的指令。透過發送將使用者角色更新為 'administrator' 的指令，攻擊者成功實現了權限提升，獲得了受影響 WordPress 網站的完整管理控制權 [1]。這種存取等級允許進一步的惡意行動，例如上傳後門程式、修改內容或注入垃圾訊息。

3. 技術修補與緩解措施

廠商在 3.1.4 版本中透過對 REST API 路由註冊實施最小但有效的更改來解決此關鍵漏洞。修復方法涉及明確地將 'show_in_index' => false 參數加入到傳遞給所有「No-Auth URL endpoints」的 register_rest_route() 參數陣列中 [1]。

下方修補後的程式碼片段展示了修正動作。透過將 'show_in_index' 設定為 false ，這些端點不再列於公開的 REST API 索引中，從而防止了 bearer token 的未經驗證暴露： 

  1. // Patched Code Snippet in AI Engine >= 3.1.4
  2. // No-Auth URL endpoints (with token in path)
  3. $noauth_enabled = $this->core->get_option( 'mcp_noauth_url' );
  4. if ( $noauth_enabled && !empty( $this->bearer_token ) ) {
  5.     // Endpoint for Server-Sent Events (SSE)
  6.     register_rest_route( $this->namespace, '/' . $this->bearer_token . '/sse', [
  7.         'methods' => 'GET',
  8.         'callback' => [ $this, 'handle_sse' ],
  9.         'permission_callback' => function ( $request ) {
  10.             return $this->handle_noauth_access( $request );
  11.         },
  12.         'show_in_index' => false, // <-- THE FIX: Prevents token exposure
  13.     ] );
  15.     // ... other patched route registrations
  16. }

此修復凸顯了 API 開發中的一個基本安全原則：包含敏感資訊或專供內部/特定使用的端點，應明確地從公共發現機制中隱藏。該漏洞的發生取決於「No-Auth URL」設定是否啟用（預設為停用），但當該功能啟用時，token 的暴露是一個關鍵的設計缺陷 [1]。

4. 對 WordPress REST API 安全的廣泛影響

CVE-2025-11749 漏洞作為一個重要的案例研究，說明了與擴展 WordPress REST API 相關的安全陷阱。核心問題不在於 WordPress REST API 框架本身存在缺陷，而是在於實作客製化插件功能時的設定錯誤。開發人員在註冊客製化路由時必須格外小心，特別是當這些路由涉及敏感資料或繞過標準身份驗證機制時。

'show_in_index' 參數是管理端點可發現性的關鍵控制項。雖然它不提供身份驗證層，但它的誤用可能導致敏感資訊暴露，如此處所示。保護客製化 REST API 端點的最佳實踐應包括：

  • 最小暴露原則： 對於任何非供公眾發現的端點，明確設定 'show_in_index' => false 。
  • 強健的身份驗證與授權： 實施嚴格的 permission_callback 函數，以確保只有經過授權的使用者或系統可以存取該端點，無論其可發現性如何。
  • Token 管理： 避免將敏感的 token 直接嵌入 URL 路徑中。如果必須使用 token，應透過請求標頭（例如 Authorization: Bearer ）安全地傳輸，並以嚴格的存取控制進行管理。

將 bearer token 用於 URL 路徑的架構決策，加上未能將端點從索引中隱藏，為此關鍵漏洞創造了完美的條件。此事件強調了在為廣泛使用的平台開發擴充功能時，進行徹底的安全稽核和遵守既定的安全準則的必要性。

5. 結論

AI Engine WordPress 插件中的權限提升漏洞（CVE-2025-11749）是 REST API 路由註冊中設定錯誤的直接結果，導致關鍵的 bearer token 未經驗證即被暴露。攻擊路徑簡單明了，允許任何未經驗證的使用者在啟用了「No-Auth URL endpoints」功能的受影響網站上獲得管理控制權。迅速實施的更新程式（即在路由參數中加入 'show_in_index' => false ）透過將端點從公共發現中移除，有效地降低了風險。這個案例提供了一個寶貴的教訓，說明了在擴展平台 API 時，特別是處理敏感的身份驗證資料時，細心配置和遵守安全最佳實踐的重要性。

參考文獻

  1. 100,000 WordPress Sites Affected by Privilege Escalation Vulnerability in AI Engine WordPress Plugin