TL;DR

一個高嚴重性的本地文件包含 (LFI) 漏洞 (CVE-2025-69397, CVSS 8.1) 影響 Tint WordPress 主題版本至 1.7。該問題可被未經身份驗證的攻擊者利用，並可能洩露敏感文件（例如，wp-config.php），並且—當與其他技術（如日誌污染）鏈接時—可能導致遠程代碼執行。在撰寫本文時，尚未公開可用的官方修補程序。如果您運行 Tint (≤1.7)，請將此視為緊急事件：立即採取緩解措施，通過您的 WAF 啟用虛擬修補，並遵循以下恢復指導。.

本公告由香港的安全專業人士準備，旨在幫助網站擁有者、開發人員和主機識別風險、阻止利用並安全恢復。.

為什麼這很重要

本地文件包含允許攻擊者使應用程序包含來自服務器文件系統的文件。最常見的直接影響是洩露包含憑證和秘密的配置文件（數據庫密碼、鹽值、API 密鑰）。在 WordPress 環境中，洩露 wp-config.php 或其他敏感文檔可能導致整個網站接管或在結合其他因素（可寫日誌、弱文件權限、上傳/執行路徑）時升級為遠程代碼執行。.

• 影響：Tint 主題版本 ≤ 1.7
• 漏洞類型：本地文件包含 (LFI)
• CVE：CVE-2025-69397
• CVSS：8.1（高）
• 所需權限：無（未經身份驗證）
• 官方修復：在發布時未公開可用

LFI 漏洞通常如何運作（簡要技術入門）

當應用程序代碼使用未經嚴格驗證或白名單的用戶控制輸入構造文件路徑，然後打開或包含該路徑時，就會產生 LFI。例如：

<?php

如果 $page 是不受控制的，攻擊者可以提供路徑遍歷序列 (../) 來逃脫預期目錄並包含任意文件：

• /wp-content/themes/tint/?page=../../../../wp-config
• /wp-content/themes/tint/?file=../../../.env

即使是非 PHP 文件也可以洩露憑證，如果其內容被回顯。攻擊者還可以使用流包裝器 (php://filter) 來讀取源代碼或將 LFI 與日誌污染鏈接以實現代碼執行。.

需要注意的常見有效載荷：

• ../../../../wp-config.php
• php://filter/convert.base64-encode/resource=…
• expect://, data://, zip://（取決於服務器配置）

現實攻擊場景

1. 文件披露：攻擊者使用路徑遍歷來包含 wp-config.php 並提取數據庫憑證。.
2. 日誌污染 → RCE: 通過 LFI 寫入日誌文件的惡意有效負載被包含，執行代碼。.
3. 敏感文件暴露: .env、備份或其他配置文件被暴露。.
4. 橫向移動: 攻擊者使用憑證創建管理用戶、安裝後門或竊取數據。.

即使漏洞最初似乎僅洩漏數據，因為鏈接風險，仍應將其視為立即威脅。.

嘗試利用的指標（要尋找的內容）

檢查訪問和錯誤日誌以尋找探測或利用的跡象：

• Requests containing many ../ sequences (URL-encoded or plain): ..%2f, ..%2f..%2f
• 包含 php://filter、data:、expect:、zip:、phar:// 的請求
• 參考 wp-config.php、.env、.git、composer.json、備份文件（.bak、.old、.sql）的請求
• 向主題路徑發送的請求，帶有查詢參數，如 ?page=、?file=、?template=、?tpl=、?inc=
• 長的 base64 編碼字符串或典型的日誌中毒有效負載模式
• 對於不應可訪問的文件，意外的 200 響應
• 新的管理用戶、對 wp_options 的更改或意外的插件/主題文件

如果發現可疑條目，立即保留日誌（下載並存檔）並進行控制。.

立即緩解檢查清單（現在優先考慮這些）

如果您運行易受攻擊的 Tint 版本的網站，請立即執行以下步驟。這些步驟的順序是為了快速降低風險。.

1. 備份 — 在進行更改之前，先進行完整的離線備份（文件 + 數據庫）。這樣可以保留證據和恢復點。.
2. 暫時切換活動主題 — 如果可能，切換到默認的、受信任的 WordPress 主題，直到問題解決。.
3. 禁用或移除 Tint 主題 — 如果不需要 Tint，請從網頁根目錄中移除主題資料夾。如果必須暫時保留，請限制對主題目錄的訪問。.
4. 通過您的 WAF 應用虛擬修補 — 在您的邊緣或網頁伺服器 WAF 上啟用路徑遍歷和 LFI 保護。阻止包含編碼/解碼 ../ 序列和流包裝器的請求，並阻止嘗試獲取敏感檔名。.
5. 限制對敏感檔案的網頁訪問 — 使用網頁伺服器規則（Apache/Nginx）拒絕訪問 wp-config.php、.env、.git 和常見備份檔名。.
6. 加強文件權限 — 將 wp-config.php 設置為限制性權限（例如，440 或 400，視情況而定）。將檔案保持在 644，目錄保持在 755；限制寫入權限。.
7. 禁用 WordPress 中的檔案編輯 — 添加到 wp-config.php：

   define( 'DISALLOW_FILE_EDIT', true );

   注意：DISALLOW_FILE_MODS 將防止插件/主題的安裝和更新；使用時請注意。.

8. 旋轉憑證 — 如果懷疑洩露，請更換資料庫憑證、WordPress 鹽值、API 金鑰和任何可能已暴露的令牌。.
9. 掃描是否被入侵 — 進行徹底的惡意軟體掃描，檢查上傳中的新 PHP 檔案、修改的時間戳或混淆代碼（eval、base64_decode）。.
10. 監控日誌 — 保留並監控訪問/錯誤日誌。如果需要，暫時增加日誌記錄並觀察重複嘗試。.

如果您管理多個網站，請在整個系統中應用 WAF 規則，以減少掃描和利用，同時進行網站級別的修復。.

分層事件控制（建議的方法）

分層響應以減少即時風險和後續影響：

• 虛擬修補： 在邊緣或網頁伺服器上部署精確的 WAF 規則，以阻止已知的利用模式，而不觸及應用程式代碼。.
• 惡意軟體檢測： 進行檔案審計以識別妥協指標和可疑檔案。.
• 文件完整性監控： 對匹配 webshell 或混淆代碼模式的新檔案或修改檔案發出警報。.
• 網頁伺服器級別的訪問控制： 強制對關鍵文件執行拒絕規則，並防止在上傳目錄中執行 PHP。.
• 取證和日誌記錄： 保留日誌和文件系統快照以供調查和事件後分析。.

示例 WAF 規則和正則表達式（供安全工程師使用）

使用以下模式作為指導。根據您的 WAF 平台（mod_security、Cloud WAF、nginx 等）調整語法。在學習/記錄期間後僅在阻止模式下部署和監控，以限制誤報。.

1) 阻止常見的路徑遍歷序列（包括 URL 編碼變體）

正則表達式：(\./../|\.\.\\|%2e%2e%2f|%2e%2e%5c)

SecRule REQUEST_URI|ARGS|ARGS_NAMES "@rx (\.\./|\.\.\\|%2e%2e%2f|%2e%2e%5c)" \
  "id:100001,phase:2,t:none,deny,status:403,msg:'Blocked path traversal attempt',log"

2) 阻止 php://filter 和其他流包裝器

正則表達式：(?i)(php://filter|data:|expect://|zip://|phar://|gopher://)

SecRule REQUEST_URI|ARGS|ARGS_NAMES "@rx (?i)(php://filter|data:|expect://|zip://|phar://|gopher://)" \"

3) 阻止嘗試獲取敏感文件名

正則表達式：(?i)(wp-config\.php|\.env|\.git|composer\.json|config\.inc\.php|\.htpasswd|backup.*\.sql|dump.*\.sql)

SecRule REQUEST_URI|ARGS|ARGS_NAMES "@rx (?i)(wp-config\.php|\.env|\.git|composer\.json|config\.inc\.php|\.htpasswd|backup.*\.sql|dump.*\.sql)" \"

4) 阻止參數中的 PHP 代碼（啟發式）

正則表達式：(?i)(<\?php|\bbase64_decode\(|eval\(|system\(|passthru\(|shell_exec\(|exec\()

SecRule ARGS|REQUEST_BODY "@rx (?i)(<\?php|\bbase64_decode\(|eval\(|system\(|passthru\(|shell_exec\(|exec\()" \"

5) 阻止非常長的參數值

檢測異常長的單個參數值（例如，> 2000 字符）：

SecRule ARGS_NAMES|ARGS "@gt 2000" "id:100005,phase:2,deny,status:403,msg:'阻擋極長的參數',log"

注意：

• 在可能的情況下，記錄和調整規則以減少誤報，然後再進行全面阻擋。.
• 涵蓋 URL 編碼變體和多種 HTTP 方法。.
• 將白名單限制為高度信任的 IP；避免廣泛的白名單。.

加固 WordPress 和伺服器（長期修復）

立即緩解措施至關重要。為了長期的韌性，應用以下控制措施：

1. 保持組件更新 — 主題、插件和核心更新是你的第一道防線。監控供應商的建議並及時應用補丁。.
2. 最小特權 — 在專用用戶下運行服務；僅給予數據庫帳戶所需的權限。.
3. 限制上傳和執行 — 在上傳中拒絕 .php 執行，並在伺服器級別驗證上傳文件類型：

   location ~* /wp-content/uploads/.*\.(php|phtml|phps)$ {

4. 禁用不必要的 PHP 包裝器 — 如果不需要 phar 或其他包裝器等功能，則在 PHP 配置中限制它們。.
5. 安全標頭和 TLS — 強制使用 HTTPS 並應用 HSTS、X-Frame-Options、X-Content-Type-Options 和合理的 Content-Security-Policy。.
6. 分開的環境 — 不要在生產環境中暴露暫存或本地環境文件。將備份和轉儲保留在網頁根目錄之外。.
7. 安全日誌 — 確保日誌不是全世界可寫的並且已輪換。在寫入日誌之前清理用戶輸入以減少日誌中毒風險。.
8. 不可變部署 — 優先使用受控工件的 CI/CD 部署，而不是在生產環境中進行實時安裝/編輯。.

事件響應和恢復（如果懷疑被攻擊）

如果懷疑被利用，將網站視為已被攻擊，並遵循標準事件響應步驟：

1. 隔離 — 在調查期間將網站下線或在防火牆上阻止外部流量。保留日誌和快照。.
2. 保留證據 — 保存完整的文件系統和數據庫備份（哈希並安全存儲）。不要覆蓋日誌。.
3. 分流 — 確定修改過的文件、網絡殼、混淆的 PHP（eval/base64 結構）、意外的管理用戶和計劃任務。.
4. 清理 — 刪除惡意文件，從經過驗證的來源恢復核心文件，並考慮從已知良好的備份中恢復，該備份是在被攻擊之前製作的。.
5. 旋轉密鑰 — 更改 WordPress 的鹽值、數據庫密碼、API 密鑰和可能已暴露的其他憑證。.
6. 監控 — 在恢復後增加日誌記錄和監控；在確認清理的同時保持虛擬補丁處於活動狀態。.
7. 根本原因分析 — 確定被利用的文件/參數並修復代碼路徑。如果易受攻擊的組件是 Tint 主題且不存在補丁，則在發布官方修復之前刪除或隔離它。.

如果缺乏內部專業知識，請聘請合格的事件響應團隊或您的託管提供商的安全專家。.

對開發人員和主題作者的建議

1. 避免根據未經驗證的用戶輸入直接包含文件。使用嚴格的白名單將鍵映射到文件名。.
2. 標準化和驗證路徑；使用 realpath() 並確保解析的路徑位於允許的目錄內。.
3. 清理和驗證所有輸入，包括查詢參數、標頭和 POST 主體。.
4. 實施安全的模板加載器，只接受映射到內部模板的已知鍵：

   <?php

5. 安全記錄 — 避免以可執行形式將原始用戶輸入寫入日誌，並確保日誌無法被網絡服務器執行。.
6. 將靜態分析、代碼審查和安全檢查集成到 CI 管道中；將審計重點放在文件包含點上。.

檢測：自動和手動檢查

• 自動掃描 — 運行檢測 LFI 模式和主題特定問題的掃描器；啟用文件完整性監控。.
• 手動代碼審查 — 搜尋包含/要求/file_get_contents/fopen/readfile 的變數，這些變數來自 $_GET/$_POST/$_REQUEST。.
• 日誌審查 — Grep access logs for ..%2f, php://filter, wp-config.php, .env, base64 patterns.
• 外部驗證 — 在測試環境中從外部視角測試控制，以確認 WAF 規則阻止利用模式。請勿在生產環境中進行未授權測試。.

常見問題

問：如果我在我的實時網站上不使用 Tint 主題，我是否安全？

答：如果未安裝或未啟用 Tint，則您不會受到此主題特定問題的影響。但是，請確認已從主題目錄中刪除過時或未使用的主題——許多網站保留舊主題。刪除任何未使用的主題和插件。.

問：我可以僅阻止所有包含 ../ 的請求嗎？

答：阻止 ../ 模式很重要，但攻擊者通常使用編碼和流包裝器。使用包含包裝器阻止、敏感文件名阻止和注入 PHP 內容的啟發式的分層規則集。.

問：輪換數據庫憑據會停止攻擊嗎？

答：在懷疑洩露後，輪換憑據是必須的，但在控制和證據收集後進行輪換。輪換可以防止進一步濫用洩露的憑據，但不會移除攻擊者可能安裝的任何後門。.

問：官方修補程序何時可用？

答：在撰寫本文時，尚未公開發布官方修復。請監控主題作者的官方渠道，並在可用時立即應用修補程序。在此之前，請使用此處概述的緩解措施。.

短期事件應對手冊（複製/粘貼檢查清單）

1. 備份文件 + 數據庫（離線）
2. 啟用虛擬修補規則（WAF 阻止 LFI 語法）
3. 將主題切換為安全的默認主題或刪除 Tint 主題
4. 限制對 wp-config.php 和其他敏感文件的網絡訪問
5. 執行全面的惡意軟件掃描和文件完整性檢查
6. 輪換數據庫憑據和 WordPress 鹽值
7. 監控日誌以尋找新的利用嘗試
8. 當清理完成後，如有需要，修補並從已知良好的備份中恢復

結論 — 實用摘要和後續步驟

此影響 Tint 主題 (≤ 1.7) 的本地文件包含問題為高優先級。在確認之前，假設最壞情況。立即步驟：

1. 包含： 啟用 WAF 保護，並考慮將網站下線以進行調查。.
2. 減輕： 部署虛擬補丁以阻止路徑遍歷、危險包裝器和訪問敏感文件名。.
3. 調查： 保存日誌並掃描是否有妥協的證據。.
4. 恢復： 移除惡意內容，輪換密鑰，並根據需要從經過驗證的備份中恢復。.

如果您管理多個 WordPress 網站，請廣泛應用保護規則，同時協調更新和修復。如果您需要專業協助，請尋求經驗豐富的 WordPress 事件響應專家或您的主機安全團隊。.

保持警惕，避免運行不受信任的代碼，並將任何未經身份驗證的文件包含問題視為緊急安全事件。.

— 香港安全專家