跳到主要內容

FaceHugger漏洞：Hugging Face Diffusers恐遭遠端執行程式碼 | FaceHugger Flaw: Hugging Face Diffusers Faces RCE Risk

By Kit 小克 | AI Tool Observer | 2026-08-04

🇹🇼 FaceHugger漏洞：Hugging Face Diffusers恐遭遠端執行程式碼

FaceHugger 是資安團隊 Zafran Labs 於 2026 年 8 月揭露的一組漏洞代號，鎖定 Hugging Face 熱門圖像生成套件 Diffusers，只要載入惡意打造的模型儲存庫，就可能在你的機器上遠端執行任意程式碼。這波揭露一共包含三個 CVE，影響的是幾乎所有 AI 開發者都在用的 from_pretrained() 載入流程，凸顯 AI 供應鏈安全的老問題又出現新變種。

FaceHugger 漏洞到底是什麼？

FaceHugger 泛指三個能繞過 Diffusers 安全機制的漏洞：CVE-2026-44827（CVSS 8.8）、CVE-2026-45804（CVSS 7.5）與 CVE-2026-44513（CVSS 8.8），核心問題都指向同一個機制失靈——trust_remote_code 安全開關本該擋下未經審核的自訂程式碼，卻被繞過了。

trust_remote_code 為什麼會失效？

Diffusers 原本設計是：沒指定 custom_pipeline 時，載入器會去找一個叫 None.py 的檔案，但檢查存在性時走的是另一條程式碼路徑，沒把 None.py 算進去。結果只要儲存庫裡真的塞一個叫 None.py 的檔案，即使 trust_remote_code=False（也是預設值），攻擊者的程式碼還是會在你載入模型時被執行。另一個變種則是利用 hf_hub_download 與 snapshot_download 兩次 HTTP 呼叫之間約 0.3 秒的競態視窗，偷天換日置換設定檔。

誰會受影響？該怎麼修？

只要你的專案、CI/CD 流程或容器映像檔中有呼叫 Diffusers 載入來路不明的模型儲存庫，就在風險範圍內——一次中毒的模型載入,就足以讓攻擊者拿到企業內網的初始立足點,而不只是單一應用程式受害。好消息是，Diffusers 官方已在 0.38.0 版修補完畢（2026 年 5 月釋出）。實務建議：

  • 立刻升級到 Diffusers 0.38.0 或以上版本
  • 不要對不熟悉來源的 Hub 儲存庫使用 trust_remote_code=True
  • CI/CD 與容器建置流程中鎖定套件版本，避免自動拉取未驗證的模型
  • 盤點現有專案是否有引用第三方 Diffusers pipeline，逐一檢查更新

Kit 小克怎麼看

這次 FaceHugger 再次證明，AI 供應鏈的攻擊面不只在模型權重本身，連「載入模型」這個動作都可能是後門。Hugging Face 生態系規模龐大，任何一個安全開關失靈都是全網開發者共同承擔的風險。如果你的專案還在用舊版 Diffusers，這次真的別拖，先升級再說。好不好用，試了才知道。

🇺🇸 FaceHugger Flaw: Hugging Face Diffusers Faces RCE Risk

FaceHugger is the name security firm Zafran Labs gave to a set of vulnerabilities disclosed in August 2026, targeting Hugging Face's popular Diffusers library for image generation. Loading a maliciously crafted model repository can trigger remote code execution on your machine — and three CVEs are involved, all hitting the near-universal from_pretrained() loading path used across the AI developer ecosystem.

What exactly is the FaceHugger flaw?

FaceHugger covers three bugs that bypass Diffusers' safety checks: CVE-2026-44827 (CVSS 8.8), CVE-2026-45804 (CVSS 7.5), and CVE-2026-44513 (CVSS 8.8). All three trace back to the same failure point — the trust_remote_code safeguard, meant to block unreviewed custom code, doesn't actually block it.

Why does trust_remote_code fail here?

When no custom_pipeline is specified, Diffusers' loader looks for a file literally named None.py — but the existence check runs through a different code path that never flags that filename. Drop a file called None.py into a repo, and it executes on load even with trust_remote_code=False (the default). A second variant abuses a roughly 0.3-second race window between the hf_hub_download and snapshot_download calls to swap in a malicious config before the full download completes.

Who's affected, and how do you fix it?

Any project, CI/CD pipeline, or container image that loads Diffusers models from repos you don't fully control is at risk — a single poisoned model load can hand an attacker a foothold deep inside your network, not just compromise one app. The fix: Diffusers patched all three issues in version 0.38.0, released May 2026. Practical steps:

  • Upgrade to Diffusers 0.38.0 or later immediately
  • Never set trust_remote_code=True for repos from sources you don't fully trust
  • Pin dependency versions in CI/CD and container builds to avoid pulling unverified models automatically
  • Audit existing projects for any third-party Diffusers pipelines and update them

Kit's take

FaceHugger is another reminder that the AI supply chain attack surface isn't just model weights — the act of loading a model can itself be the backdoor. Hugging Face's ecosystem is massive, so one broken safety switch becomes a shared risk for every downstream developer. If you're still on an old Diffusers version, don't wait — upgrade first, ask questions later. 好不好用，試了才知道 (You won't know if it's good until you try it).

Sources / 資料來源

常見問題 FAQ

FaceHugger 漏洞會影響哪些人？

任何在專案、CI/CD 或容器映像中使用 Hugging Face Diffusers 載入外部模型儲存庫的開發者都在風險範圍內，尤其是載入不熟悉來源的模型時。

要怎麼確認自己有沒有中招？

檢查專案使用的 Diffusers 版本，若低於 0.38.0 就有暴露風險；盤點是否曾用 trust_remote_code=True 載入第三方 pipeline。

升級到 0.38.0 就完全安全了嗎？

官方已在 0.38.0 修補三個 CVE 對應的漏洞路徑，升級是目前最直接有效的防護方式，同時建議搭配鎖定版本與來源審查等供應鏈防護措施。

trust_remote_code=False 不是預設就安全嗎？

理論上是，但 FaceHugger 正是證明即使設為 False（或不設定），攻擊者仍能透過 None.py 檔名漏洞或競態條件繞過此安全機制。

延伸閱讀 / Related Articles

AI 工具觀察站 — 每日精選 AI Agent 與工具趨勢
AI Tool Observer — Daily curated AI Agent & tool trends

留言

張貼留言

這個網誌中的熱門文章

Cursor vs GitHub Copilot vs Claude Code：AI 程式助手大比拼 | AI Coding Assistants Compared: Cursor vs GitHub Copilot vs Claude Code

By Kit 小克 | AI Tool Observer | 2026-03-27 🇹🇼 Cursor vs GitHub Copilot vs Claude Code：AI 程式助手大比拼 2026 年，AI 程式助手已經成為開發者的標配。但市場上選擇太多了，到底該用哪一個？我同時使用了 Cursor、GitHub Copilot 和 Claude Code 超過半年，以下是完整比較。 GitHub Copilot：最普及的選擇 Copilot 是最早普及的 AI 程式助手，整合在 VS Code 和各大 IDE 中。它的核心功能是 即時程式碼補全 ——你打字的時候，它自動建議下一行或下一段程式碼。 優點 ：補全速度快、整合度高、支援幾乎所有語言、Copilot Chat 可以問問題 缺點 ：上下文理解有限（主要看當前檔案和少量相關檔案）、Agent 模式仍在發展中 價格 ：個人版 /月，企業版 /月 Cursor：IDE 級別的 AI 整合 Cursor 是一個從頭打造的 AI-first IDE（基於 VS Code fork）。它不只是補全程式碼，而是把 AI 深度融入整個開發流程。 優點 ：Composer 功能可以跨檔案編輯、Agent 模式可以自主執行多步驟任務、支援切換不同 AI 模型、Tab 補全非常智慧 缺點 ：是獨立的 IDE 需要遷移、Pro 方案有使用量限制、偶爾不穩定 價格 ：免費方案有限制、Pro /月 Claude Code：終端機裡的 AI 工程師 Claude Code 走完全不同的路線——它是 CLI 工具，在終端機裡運作，不綁定任何 IDE。 優點 ：理解整個 codebase、可以執行系統指令、支援 git 操作、CLAUDE.md 定義專案規則、最強的 agentic 能力 缺點 ：沒有視覺化介面、按 API token 計費（可能很貴）、需要習慣 CLI 工作流 價格 ：按 API 使用量計費，或透過 Max 訂閱方案 關鍵差異比較 即時補全 ：Copilot ≈ Cursor > Claude Code（無此功能） 跨檔案理解 ：Claude Code > Cursor > Copilot Agentic 能力 ：Claud...
閱讀完整內容

Google Ironwood TPU v7 推理專用晶片解析：效能追平 NVIDIA、成本低 44%，AI 晶片戰爭正式開打 | Google Ironwood TPU v7 Explained: Matching NVIDIA Performance at 44% Lower Cost — The AI Chip War Heats Up

By Kit 小克 | AI Tool Observer | 2026-04-21 🇹🇼 Google Ironwood TPU v7 推理專用晶片解析：效能追平 NVIDIA、成本低 44%，AI 晶片戰爭正式開打 Google Ironwood TPU 是什麼？為什麼它讓 NVIDIA 緊張？ Google Ironwood TPU（代號 TPU v7）是 Google 第七代自研 AI 晶片，也是第一款 專為推理（inference）設計 的 TPU。在 AI 模型越來越大、推理需求暴增的時代，Google 不再只依賴 NVIDIA GPU，而是推出自己的推理專用晶片來搶市場。 Ironwood TPU v7 規格有多強？ 每顆 Ironwood TPU 提供 4.6 petaFLOPS 的 FP8 運算效能 ，搭載 192 GB HBM3E 記憶體，頻寬達 7.37 TB/s。單顆效能略高於 NVIDIA B200（4.5 petaFLOPS），接近 GB300 的 5 petaFLOPS。 更驚人的是規模化能力：Ironwood 可擴展至 9,216 顆晶片組成超級叢集 ，總算力達 42.5 ExaFLOPS，遠超 NVIDIA GB300 NVL72 系統的 0.36 ExaFLOPS。共享記憶體池高達 1.77 PB，解決了大型模型推理時的資料瓶頸問題。 Ironwood TPU 比 NVIDIA 便宜多少？ 根據分析，Ironwood 的 整體擁有成本（TCO）比 NVIDIA GB200 低約 44% 。在能效方面，Ironwood 的 FP8 效能達每瓦 5.42 TFLOPS，而 GB300 為 3.57 TFLOPS/W，Google 晶片的能效高出約 52%。 為什麼 Google 要做推理專用晶片？ AI 產業正從「訓練時代」轉向「推理時代」。當 ChatGPT、Gemini、Claude 等 AI 助手每天處理數十億次查詢時，推理運算的需求遠超過訓練。Google 稱之為「推理時代（age of inference）」，而 Ironwood TPU 就是為這個時代量身打造的武器。 對開發者和企業有什麼影響？ Ironwood TPU 目前 只能透過 Google Cloud 使用，無法...
閱讀完整內容

Claude Code 實測：AI 幫你寫程式到底行不行？ | Claude Code Review: Can AI Really Code for You?

By Kit 小克 | AI Tool Observer | 2026-03-27 🇹🇼 Claude Code 實測：AI 幫你寫程式到底行不行？ Claude Code 是 Anthropic 推出的命令列 AI 程式助手，直接在你的終端機裡運作。跟其他 AI 程式工具不同的是，它不是 IDE 外掛，而是一個獨立的 CLI 工具，可以讀取你的整個 codebase、執行指令、甚至幫你做 git 操作。我實際用了幾個月，以下是真實心得。 安裝與設定 安裝非常簡單，透過 npm 就能搞定： npm install -g @anthropic-ai/claude-code 。啟動後它會要求你登入 Anthropic 帳號或設定 API key。整個流程不到五分鐘。 實際使用體驗 Claude Code 最強的地方在於 它理解你的整個專案 。你不需要手動貼程式碼，它會自己讀取相關檔案、分析程式結構，然後給出建議或直接修改。實測幾個場景： Bug 修復 ：描述錯誤現象，它能自動找到問題檔案並提出修正，準確率大約 70-80% 新功能開發 ：給它需求描述，它能產出可用的初版程式碼，但通常需要人工調整細節 程式碼重構 ：這是它最擅長的。重新命名變數、抽取函式、調整架構，做得又快又好 寫測試 ：給它一個函式，它能產生相當完整的測試案例 優缺點分析 優點： 深度理解 codebase，不是只看單一檔案 可以執行 shell 指令，直接跑測試、裝套件 支援 CLAUDE.md 讓你定義專案規則 agentic 模式下可以自主完成多步驟任務 缺點： API 費用不便宜，大型專案一天可能花 10-30 美元 偶爾會過度修改，改了不該改的地方 對非英語的程式碼註解理解力稍弱 需要良好的網路連線 適合誰用？ 如果你是全端開發者、需要處理多個專案、或者經常做重構，Claude Code 絕對值得一試。但如果你只是寫簡單的腳本，免費的 Copilot 可能就夠了。 Kit 的結論： Claude Code 是目前最接近「AI 工程師」的工具。它不完美，但確實能大幅提升生產力。好不好用？試了才知道。 🇺🇸 Claude Code Review: Can AI Really Code for You?...
閱讀完整內容