什麼是本地文件包含 (LFI)？

本地文件包含 (LFI) 是一種網絡應用程序漏洞類別，攻擊者可以使伺服器端腳本包含並評估來自本地文件系統的文件。在 PHP 應用程序中，如 WordPress 主題，這通常源於不安全地使用 include()、require() 或類似函數，其中用戶可控參數選擇文件。成功利用可能會揭示敏感文件 (wp-config.php、.env、備份)、洩露憑證，並在某些配置中導致代碼執行。.

LFI 與遠程文件包含 (RFI) 不同 — 現代 PHP 通常禁用遠程包含，因此 LFI 是更常見的現實風險。本地文件通常包含秘密和配置，使 LFI 對攻擊者極具價值。.

AC 服務主題漏洞：快速事實

• 受影響產品：“AC 服務 | HVAC、空調及暖氣公司”WordPress 主題 (主題系列：Window / AC 服務)
• 易受攻擊的版本：≤ 1.2.5
• 漏洞類型：本地文件包含 (LFI)
• CVE：CVE-2026-27326
• 報告者：獨立研究人員 (公開披露日期 2026-03-04)
• 所需特權：無 — 未經身份驗證
• 影響：本地文件泄露（包括 wp-config.php）、潛在的數據庫憑證洩漏、根據伺服器配置和可寫上傳目錄可能導致的網站接管
• 修補狀態：將活動網站視為有風險，直到供應商發布確認的修補程序並且您應用它。.

為什麼這個漏洞對 WordPress 網站是危險的

使這個 LFI 嚴重的關鍵屬性：

1. 未經身份驗證的利用 — 攻擊者可以在沒有帳戶的情況下進行探測和利用。.
2. 敏感的本地文件 — WordPress 安裝通常包含 wp-config.php、日誌、備份和其他包含憑證和秘密的文件。.
3. 自動化大規模掃描 — 攻擊者部署機器人快速發現和利用已披露的易受攻擊主題。.
4. 轉向完全妥協 — 曝露的數據庫憑證可能導致內容操縱、管理員創建或持久後門。.
5. 供應鏈風險 — 在許多客戶網站上部署的購買主題可能導致廣泛曝光。.

鑑於這些因素，立即實施分層緩解措施：阻止利用嘗試、檢測過去的利用並修補根本原因。.

攻擊者如何 (並且通常會) 濫用 LFI

攻擊者通常遵循這本劇本：

1. 指紋識別 — 識別使用易受攻擊主題和版本的網站。.
2. 探測 — 向已知的易受攻擊端點發送精心製作的請求，通常帶有目錄遍歷序列（../ 或編碼等效物）。.
3. 數據提取 — 檢索 wp-config.php 和其他包含憑證或鹽的文件。.
4. 憑證使用或提升 — 使用暴露的數據庫憑證來更改數據、創建管理用戶或獲得進一步訪問。.
5. 持久性和清理 — 安裝後門/網頁外殼並刪除日誌以隱藏痕跡。.

及早阻止 LFI 嘗試是一種有效的減少風險和阻止許多自動攻擊的方法。.

受損指標（IoCs）和檢測指導

在日誌和文件系統中尋找這些跡象 — LFI 利用嘗試的常見 IoC：

• HTTP requests to theme endpoints with query parameters containing traversal payloads (“../” or “..%2F”).
• 參數中包含的請求，例如 檔案=, 頁面=, 模板=, 包含=, 包含=, 路徑=, 檢視=, ，等等，特別是如果它們映射到主題代碼。.
• 對於應該返回 404/403 的請求，重複的 200 響應。.
• 有關 wp-config.php、.env 或備份文件的網絡訪問證據。.
• 在上傳、wp-content 或主題目錄中出現的新或修改的 PHP 文件（可能是網頁外殼）。.
• 意外的數據庫更改（新管理用戶、帶有惡意軟件的修改帖子）。.
• 提升的錯誤日誌顯示文件內容或堆棧跟蹤。.
• 網頁伺服器意外的外發連接。.

你現在可以採取的檢測行動：

• 檢查網絡伺服器訪問日誌，查找包含 ../ 或嘗試獲取敏感文件名的請求。.
• 掃描文件系統以查找最近修改的文件和上傳中的意外 PHP 文件。.
• 在數據庫中搜索不熟悉的用戶和可疑的帖子內容。.
• 使用您的伺服器或託管提供者的日誌檢查被阻止或可疑的請求。.

您現在可以立即應用的緩解措施（不需要主題更新）

如果您運行受影響的主題並且無法立即更新，請應用這些務實的步驟：

1. 在邊緣阻止 LFI 模式（虛擬修補）
   實施阻止目錄遍歷的伺服器或防火牆規則（../ 和編碼形式）、空字節和包裝方案（php://, 數據：, file:）。在可能的情況下，限制對主題包含端點的訪問僅限於受信來源。.
2. 限制對敏感檔案的直接訪問
   添加網頁伺服器規則以拒絕對 9. 或使用使會話失效的插件。在可行的情況下強制執行雙因素身份驗證。, .env, .git 和其他已知敏感名稱的請求。.
3. 鎖定主題文件
   暫時移除或重新命名主題中調用 include() 並使用不受信輸入的可疑入口文件。如果不需要易受攻擊的文件來提供公共功能，請將其移出網頁根目錄。.
4. 加強文件權限和 PHP 執行
   確保上傳目錄不執行 PHP。應用最小權限（文件 644，目錄 755），並驗證網頁伺服器用戶無法寫入核心主題或插件目錄。.
5. 如果發現洩露的證據，請輪換密鑰和憑證
   如果 wp-config.php 或其他秘密被訪問，請立即輪換數據庫憑證和任何暴露的 API 密鑰，並相應更新配置。.
6. 監控和隔離可疑主機
   在調查期間阻止攻擊者 IP。如果存在持久的後門或 shell，考慮隔離主機以防止進一步損害。.
7. 在修復之前備份
   創建完整的文件系統和數據庫備份以保留證據並提供恢復點。.

緊急應用這些控制措施——它們降低了立即風險並提供了進行全面修復的時間。.

安全代碼修復和開發者指導

如果您維護主題或與開發人員合作，通過消除未經驗證的用戶控制輸入來修復根本原因，以進行 include/require 操作。最強的控制是白名單。.

建議的安全模式

1. 使用允許的模板或文件的白名單。將邏輯名稱映射到實際文件：

// 允許的模板映射

2. 永遠不要將原始輸入傳遞給 include/require。白名單是最強的控制；basename()/realpath() 只是部分緩解措施。.

3. 如果將輸入轉換為路徑是不可避免的，請標準化並確保文件位於安全的基目錄內：

$base = realpath( get_template_directory() . '/templates' );

4. 避免動態代碼評估 (eval(), create_function 等)，並將文件內容視為數據，而不是可執行代碼。.

5. 確保網頁伺服器進程對文件操作具有最小權限，並且不能任意修改主題代碼。.

對於主題更新，包含安全單元測試和專注於 include() 使用的代碼審查。自動靜態分析可以幫助檢測風險調用。.

完整的修復檢查清單 (優先級)

按緊急程度遵循這些步驟：

立即（幾小時內）

• 應用邊緣/伺服器規則以阻止 LFI 模式和針對已知易受攻擊端點的請求。.
• 通過 nginx/apache 規則拒絕對敏感文件的直接訪問。.
• 在更改之前創建完整備份（文件系統 + 數據庫）。.

短期（24–72 小時）

• 如果有供應商補丁可用，請在所有網站上更新主題（先在測試環境中測試）。.
• 如果沒有補丁，請在生產環境中禁用或替換易受攻擊的主題；在修復期間切換到默認或已知良好的主題。.
• 如果懷疑遭到入侵，請輪換數據庫和 API 憑證。.

中期（1–2 週）

• 用來自經過驗證的來源或備份的乾淨副本替換已修改或惡意的文件。.
• 審計惡意用戶、計劃任務和意外的外部連接。.
• 執行全面的惡意軟件掃描和文件完整性檢查。.

長期（持續進行）

• 強化檔案權限並禁用上傳中的 PHP 執行。.
• 實施日誌記錄和異常監控；保持系統更新。.
• 使用暫存環境進行更新並維護事件響應計劃。.

對於 WordPress 主機和網站擁有者的加固建議

• 維護並測試完整網站備份和恢復程序。.
• 對檔案系統和資料庫帳戶應用最小權限原則。.
• 強制使用強密碼並定期更換（資料庫密碼、鹽值、API 金鑰）。.
• 通過管理介面禁用檔案編輯： define('DISALLOW_FILE_EDIT', true);
• 定期執行漏洞掃描和檔案完整性檢查。.
• 配置網頁伺服器以拒絕訪問 .git, .env 和備份檔案。.
• 在可行的情況下限制不必要的外發伺服器連接。.
• 為管理帳戶啟用雙因素身份驗證並監控登錄嘗試。.

事件響應：如果懷疑您的網站被入侵該怎麼辦

1. 隔離
   如果可能，將網站置於維護/離線模式。阻止可疑 IP 並在有主動數據外洩或持久性殼程式的情況下隔離主機。.
2. 保留證據
   在修改任何內容之前，對檔案系統和資料庫進行取證快照。保留伺服器日誌（網頁、PHP、系統日誌）。.
3. 根除
   刪除惡意檔案或從經過驗證的乾淨備份中恢復。更換憑證並使會話失效。刪除可疑的管理用戶和排程任務。.
4. 恢復
   從乾淨來源恢復服務，加固網站，並密切監控是否有再次發生。.
5. 審查並學習
   進行根本原因分析並改善防禦以降低再次發生的機會。.

如果入侵情況複雜或您缺乏內部能力，請聘請一位有經驗的合格事件響應專家，專注於 WordPress 取證調查。.

尋求專業幫助和服務

如果您需要協助實施緩解措施、執行取證分析或在多個客戶之間恢復網站，請尋求值得信賴的安全顧問或事件響應提供者。向潛在提供者詢問：

• 具備 WordPress 事件響應和取證時間線的經驗。.
• 參考資料和先前的參與摘要（根據需要進行編輯）。.
• 明確的工作範圍、交付物和包含、根除及恢復的時間表。.
• 安全處理憑證和證據保存實踐。.

為安全團隊提供安全測試指導和注意事項。

• 只測試您擁有或已獲得明確許可的系統。.
• 測試中不要包含敏感文件 — 使用無害文件確認包含行為。.
• 優先進行被動日誌分析，然後再進行主動利用測試。.
• 如果需要主動測試，請使用隔離的測試環境並保存日誌以供分析。.
• 如果發現其他問題，請遵循負責任的披露。.

公共利用代碼和大規模掃描器在披露後迅速出現；請及時採取緩解措施。.

附錄 — 伺服器規則示例（高級，使用前請測試）

您可以根據自己的環境調整的高級示例：

• 阻止直接訪問 9. 或使用使會話失效的插件。在可行的情況下強制執行雙因素身份驗證。 （Nginx 片段）： location ~* wp-config.php { 拒絕所有; }
• 拒絕包含遍歷序列的請求：拒絕包含 ../ 或編碼變體的請求，您的伺服器支持請求匹配。.
• 阻止可疑的包裝方案：拒絕包含 php://, 數據：, expect：, 等等。.

這些規則故意設計為通用 — 在部署到生產環境之前，請仔細調整和測試。.