執行摘要
2026年5月19日，影響NPM套件“sillytavern”（≤ 1.17.0）的高嚴重性伺服器端請求偽造（SSRF）漏洞被公開（CVE-2026-46372，GHSA-qg89-qwwh-5f3j）。該問題源於未經驗證的 基本網址 參數，該參數由SearXNG搜索代理集成使用。攻擊者可以利用此缺陷迫使受影響的伺服器向攻擊者控制或內部地址發送HTTP請求，可能暴露憑證、元數據端點、內部服務，或使進一步的橫向移動成為可能。該套件在版本1.18.0中已修補。如果您運行任何依賴於sillytavern或暴露反向代理功能的服務，請將此視為緊急事項。.

為什麼這對 WordPress 網站擁有者很重要

雖然此漏洞存在於NPM套件中，但現代WordPress網站通常與其他服務（Node.js微服務、聊天前端、自托管助手等）共享基礎設施。當多個服務共享相同的主機、網絡或憑證時，某個組件中的SSRF可以被武器化，以訪問WordPress應用程序或其管理員依賴的內部資源。.

• 共享主機：WordPress可能與使用Node套件的其他軟件位於同一虛擬機或容器中。.
• 混合堆疊：團隊運行混合技術工具，如果某個組件受到攻擊，可以用作樞紐。.
• SSRF風險：任何代表輸入執行外發HTTP(S)請求的組件都可能被欺騙以查詢內部端點，如元數據服務、管理API或本地管理界面。.

SSRF影響重大，因為攻擊者控制請求目標；後果範圍從憑證盜竊到在雲或私有網絡內的橫向移動。.

技術背景 — 發生了什麼

SillyTavern使用SearXNG作為某些功能的搜索代理。在易受攻擊的版本（≤ 1.17.0）中， 基本網址 配置值未經驗證。這使得攻擊者可以提供或操縱 基本網址 以便應用程序向攻擊者選擇的任意URL發出請求。.

主要特徵：

• 類別：伺服器端請求偽造（SSRF）。.
• 根本原因：對URL/配置參數的驗證不足（基本網址).
• 影響：伺服器可能被誘導請求內部IP、雲元數據端點（例如，169.254.169.254）或任何可達主機。.
• 補丁：sillytavern v1.18.0 包含驗證和限制，以防止攻擊者控制。 基本網址 值。.

參考：CVE-2026-46372，GHSA-qg89-qwwh-5f3j。.

可能的利用場景（高層次）

代表性攻擊以了解風險（未提供利用代碼）：

• 獲取雲端元數據： 請求元數據端點以獲取憑證或令牌（例如，AWS IMDS 在 169.254.169.254）。.
• 訪問內部管理界面： 訪問綁定到本地主機或內部子網的管理 API。.
• 端口掃描/發現： 使用易受攻擊的主機來映射內部 IP 範圍和服務。.
• 繞過網絡控制： 讓受害者伺服器執行被互聯網阻止的請求。.
• 數據外洩： 查詢內部調試端點並將敏感數據返回到攻擊者控制的端點。.

如何檢測利用嘗試

檢測需要關聯網絡流量和外發活動。尋找：

• 19. POST 請求到 參數中包含的請求，例如 基本網址, 代理, url, 目標. 長的、編碼的或包含憑證的值是可疑的。.
• 應用日誌： 外發請求的登錄目的地地址；外發請求頻率的激增。.
• 外發網絡/出口日誌： 從網頁進程到 169.254.169.254、127.0.0.1、RFC1918 範圍或 IPv6 連接本地地址的連接。.
• DNS 日誌： 隨機子域或不尋常解析模式的查詢。.
• WAF 日誌： 規則阻擋可疑 基本網址 值或私有 IP 模式。.
• 處理行為： 從 PHP/Node 執行環境發出網路呼叫的新或意外進程，或 CPU/DNS 峰值。.

建立正常行為的基準，以便更可靠地檢測偏差。.

立即步驟 — 接下來幾個小時該做什麼

1. 修補軟體

   如果您運行 SillyTavern 或依賴 sillytavern 的服務，請立即更新到 v1.18.0。這是正確的修復。.

2. 如果您無法立即更新，虛擬修補

   部署 WAF 規則以檢測和阻擋惡意 基本網址 使用並限制對接受代理 URL 的端點的公共訪問。.

3. 限制外發連接

   應用主機出口規則（雲安全組、防火牆、iptables）以拒絕除允許的目的地外的出站流量。至少，阻止對雲元數據端點（169.254.169.254）和內部管理網路的訪問。.

4. 隔離和調查

   如果存在指標，請隔離受影響的主機，保留日誌，並尋找憑證盜竊或持久性的跡象。.

5. 旋轉憑證和秘密（如有必要）

   如果可能查詢了元數據或管理 API，請旋轉 API 金鑰和服務憑證。.

6. 監控後續行動

   注意新帳戶、修改的配置、修改的文件或指示後續活動的排程任務。.

WAF 緩解和示例規則

以下是實用的 ModSecurity 風格範例，用於檢測和阻止常見的 SSRF 模式。在生產環境之前請在測試環境中測試這些；根據您的環境進行調整。.

1) 阻止包含 基本網址 私有 IP 或元數據端點的請求

# 檢查 baseUrl 參數是否包含私有 IP 或元數據端點"
    

目的： 拒絕請求，當 基本網址 指向本地主機、RFC1918 地址、AWS 元數據或 IPv6 連接本地地址。.

2) 拒絕嵌入憑證或可疑協議的 URL

# 阻止包含基本身份驗證憑證或危險協議的 URL"
    

3) 限制或阻止重複的代理請求

# 限速範例（概念性）"
    

與限速器集成以減少自動化利用嘗試。.

4) 阻止解析到私有地址的 DNS 查詢

如果您的 WAF 或代理支持外部檢查，解析提供的主機名，並在解析到私有 IP 時阻止。這需要仔細實施以避免 DNS 競爭條件。.

注意： 這些是防禦性模式。它們減少了暴露，但不能替代修補易受攻擊的包。.

開發人員的加固指導（代碼中的修復）

接受外部 URL 或代理配置的開發人員應採用這些做法：

• 白名單主機： 只允許應用程序合法需要聯繫的定義主機名集。.
• 拒絕非 HTTP 協議： 僅接受 http 和 https 在適當的情況下。.
• 強制主機驗證： 解析並驗證主機組件；拒絕私有範圍內的 IP。.
• 防止嵌入的憑證： 不允許包含 user:pass@host 的 URL.
• 解析並驗證： 如果允許主機名稱，則解析它們，並在結果 IP 是私有的情況下拒絕。使用安全的解析器並考慮競爭條件。.
• 超時和限制： 設置請求超時和最大重定向以避免長時間運行的請求。.
• 將配置視為敏感： 不要在沒有嚴格驗證的情況下直接使用用戶提供的值作為運行時配置。.

這些是 SillyTavern 的維護者在 v1.18.0 中實施的緩解措施類型。.

主機和網絡級別的保護

• 除非明確需要，否則防止網絡進程訪問僅限內部的服務。使用主機出口防火牆規則、雲安全組或出口代理。.
• 如果應用程序不需要，則阻止應用實例訪問雲元數據。例如，阻止網絡進程向 169.254.169.254 的出站流量。.
• 在最小特權網絡中運行服務於分段網絡。.
• 在可能的情況下，通過監控的代理路由出站請求，該代理強制執行允許列表並記錄活動。.

網絡控制限制 SSRF 可以到達的範圍，即使應用程序在一段時間內仍然脆弱。.

事件響應檢查清單（實用步驟）

1. 保留證據

   捕獲網絡、應用程序、防火牆、DNS 和網絡日誌。確保日誌不被覆蓋。.

2. 隔離

   禁用易受攻擊的功能或將主機放置在 IP 限制後面。如有需要，暫時移除公共訪問。.

3. 修補

   將 sillytavern 更新至 v1.18.0 或應用供應商建議的修復措施。.

4. 分析

   檢查訪問日誌以尋找可疑 基本網址 值，並檢查主機的外發連接和 DNS 查詢。.

5. 旋轉密鑰

   如果元數據或憑證可能已被暴露，請更換 API 密鑰和令牌。.

6. 掃描和清理

   執行惡意軟體掃描和完整性檢查，以檢測利用後的遺留物。.

7. 恢復和監控

   只有在確認系統乾淨後才恢復正常操作。至少增加 30 天的監控。.

8. 報告

   根據您的事件響應政策或法規義務，通知您的安全團隊、託管提供商或客戶。.

檢測和日誌示例以搜索

在搜索日誌或與您的託管提供商協調時使用這些指標：

• 帶有參數的請求： ?baseUrl=, ?proxy=, ?target=, ，包含的 POST/JSON 主體 基本網址 或 proxy_url.
• 包含的參數值： 169.254.169.254, 127.0.0.1, 7. ，或非 HTTP 協議（例如, 10., 172.16.–172.31., 192.168., fe80:, ::1, ，或 @ 字符（嵌入的憑證）。.
• 從您的網頁伺服器 IP 向私有範圍的外發請求激增。.
• WAF 日誌顯示 SSRF 模式的簽名觸發。.

為什麼更新仍然是最重要的步驟

WAF 規則和出口過濾是補償控制措施。它們降低風險，但不消除根本漏洞。正確的修復方法是將 sillytavern 更新至 v1.18.0，這修復了根本原因。如果攻擊者修改有效負載或合法用例繞過規則，虛擬補丁可能會失效。.

安全配置檢查清單（摘要）

• 將 sillytavern 更新至 v1.18.0（或更高版本）。.
• 部署阻止的 WAF 規則 基本網址 指向私有範圍、元數據 IP 和嵌入的憑證。.
• 限制網頁進程的外部網絡訪問；阻止應用程序進程訪問雲元數據端點。.
• 檢查應用程序代碼中的其他用戶提供的 URL 參數並相應加固。.
• 監控日誌以檢查可疑的代理使用情況，並對異常的外部連接實施警報。.
• 如果元數據或內部端點可能已被訪問，則輪換憑證。.
• 如果懷疑存在利用行為，則進行全面調查和惡意軟件掃描。.

最後的想法

SSRF 漏洞特別危險，因為它們使攻擊者能夠利用您自己的基礎設施作為偵察和攻擊平台。對於與 Node.js 服務或混合環境共享基礎設施的 WordPress 操作員來說，這個 SillyTavern SSRF 是一個提醒：

• 及時修補。.
• 在您更新的同時，將 WAF 用作臨時虛擬補丁。.
• 加固出口規則和網絡分段。.
• 監控日誌並準備好響應。.

如果您需要協助評估暴露或應用緩解措施，請尋求可信的安全顧問或您的託管提供商的事件響應團隊的幫助。保持警惕：保持軟件更新，驗證輸入，並限制每個伺服器在網絡上可以訪問的內容。.