Local / Edge実践ガイド
Hugging Face TransformersのCVE-2026-80047とは?影響範囲とローカルAI利用者の対処を整理

目次
Hugging FaceのtransformersをローカルAIで使っているなら、2026年9月1日に公開されたCVE-2026-80047 / CERT/CC VU#456290は確認しておきたい。
CERT/CCによると、Transformers 4.49.0から5.8.1には、特定のカスタム生成処理でtrust_remote_codeの確認より先にリモート Python ファイルをローカルへ取得・書き込む問題がある。
重要なのは、この問題を「Hugging Faceのモデルを開いただけで必ずコードが実行される」と大きく言い換えないことだ。
CERT/CCが説明している直接の問題は、GenerativePreTrainedModel.load_custom_generate()で、リポジトリ側のcustom_generate/generate.pyがユーザーの信頼確認より前にHugging Face モジュールキャッシュへ書き込まれる点にある。実行そのものは同意で許可判定されるが、ファイルの取得・保存が先に起きてしまう。
該当バージョンなら確認推奨。修正版が明示されるまでは未信頼リポジトリでload_custom_generateを使わない
2026年9月2日にCERT/CCのVulnerability Noteを確認した時点では、提供元のパッチまたは注意情報はまだ案内されていない。
そのため、現時点では次の順で対処するのが安全側だ。
- 自分のTransformers バージョンを確認する
- 4.49.0〜5.8.1なら該当範囲として扱う
- 未信頼のモデルリポジトリに対して
load_custom_generate()を使わない ~/.cache/huggingface/modulesに予期しないリモートモジュールがないか確認する- Hugging Face / CERT/CCから修正版・追加情報が出たら更新する
バージョンはPython環境で次のように確認できる。
python -c "import transformers; print(transformers.__version__)"
または、pip環境なら次でも確認できる。
pip show transformers
CVE-2026-80047で起きる処理順序
通常、リモートコードを必要とするモデルを扱う場合は、ユーザーがそのコードを信頼するかどうかを確認してから処理を進めるのが自然だ。
今回CERT/CCが問題としている経路では、その順序が逆になっている。
概念的には次のような流れだ。
model repositoryを参照
↓
custom_generate/generate.pyを取得
↓
ローカルmodule cacheへ書き込み
↓
trust_remote_codeの確認
本来期待したいのは、信頼確認を先に行い、拒否された場合はリモートコードを取得・保存しない流れだ。
CERT/CCによると、該当ファイルは~/.cache/huggingface/modulesへ残る可能性があり、ユーザーが信頼プロンプトを拒否しても最初の書き込みは取り消されない。
「書き込まれる」と「実行される」は分けて考える
CVE-2026-80047について、CERT/CCはリモート Python 内容が同意前にディスクへ書き込まれることを直接の問題として説明している。
一方で、同説明はモジュールの実行自体は正しく許可判定されているとも説明している。
したがって、
- 未信頼ファイルが勝手に保存される
- 保存されたPythonがその場で必ず自動実行される
は同じ意味ではない。
ただし、キャッシュが再利用される環境では、以前保存された攻撃者が制御できるファイルが後続の信頼済みの読み込みで使われる可能性があるとCERT/CCは指摘している。そのため「実行されていないから放置してよい」とも言えない。
影響するバージョン
CERT/CCが2026年9月1日に公開した情報では、影響を受けるバージョンは次の範囲だ。
| 項目 | 内容 |
|---|---|
| ライブラリ | Hugging Face Transformers |
| CVE | CVE-2026-80047 |
| CERT/CC | VU#456290 |
| 影響範囲 | 4.49.0〜5.8.1 |
| 問題の処理 | GenerativePreTrainedModel.load_custom_generate() |
| 問題 | 同意前のリモート Python ファイル取得・キャッシュ書き込み |
| 提供元パッチ | 2026年9月2日確認時点でCERT/CCは未提供と記載 |
このバージョン表は、今後Hugging Face側の修正版やCERT/CC更新で変わる可能性がある。
特に「5.8.2なら直っているはず」といった推測はしない方がよい。修正済みバージョンが公式に明示されるまでは、バージョン番号だけから修正済みと断定しないのが安全だ。
自分が影響を受けるか確認する
まず、Transformersを使っているだけで全員が同じ危険度になるわけではない。
優先して確認したいのは次の条件だ。
- PythonのTransformersを直接使っている
- バージョンが4.49.0〜5.8.1
- Hugging Faceなど外部リポジトリからモデルを取得する
- カスタム生成コードを持つモデルを扱う
load_custom_generate()を使う、またはそれを呼ぶ実装を利用している- 出所を十分確認していないモデルリポジトリも試す
逆に、GGUFをllama.cpp系実行環境で読むだけの構成を、このCVEだけを理由に同じ影響を受けるパスだと断定するのは適切ではない。
GGUFモデルをダウンロードする前に確認したい5項目で扱っているように、モデル名だけではなく配布元・形式・実行環境を分けることが重要だ。
モジュールキャッシュの確認方法
CERT/CCはHugging Face モジュールキャッシュとして~/.cache/huggingface/modulesを挙げ、予期しない内容の点検または削除を案内している。
LinuxやmacOSでは、まず内容を確認するなら次のパスを見る。
~/.cache/huggingface/modules
WindowsではHugging Faceのキャッシュ場所や環境変数設定によって実際の保存場所が変わる可能性があるため、固定パスを決め打ちせず、自分のHF_HOME / キャッシュ設定も確認したい。
重要なのは、内容を理解せずにHugging Face全キャッシュを一括削除することではない。モデル重みまで含むキャッシュを消せば、巨大なモデルを再ダウンロードすることになる場合がある。
今回CERT/CCが明示している対象はモジュールキャッシュだ。まず該当ディレクトリを確認し、利用中の環境や再現性を考えたうえで対処したい。
safetensorsだけでは今回のCVE対策にならない
safetensorsを使っているだけでCVE-2026-80047対策になる、と考えるのは正しくない。
Hugging FaceのTransformers セキュリティ Policyは、pickleなど安全でないなモデル配布ファイルに比べてsafetensorsを推奨している。これはモデル重みシリアライズ由来のリスクを減らすうえで重要だ。
しかし今回問題になっているのは、モデル重みのシリアライズ形式そのものではなく、カスタム生成用リモート Python コードの取得順序だ。
したがって、
- safetensorsかどうか
- リモート Python コードを取得・実行するか
は別のセキュリティ層として見る必要がある。
trust_remote_code=Falseでも同意前の書き込みは防げない
今回のCVEでは、そこも誤解しやすい。
普通なら「リモートコードを信頼しない」と判断すれば、そのコードはローカルへ持ち込まれないことを期待する。
しかしCERT/CCが報告した問題は、信頼判断より前にファイル書き込みが発生することだ。
つまり、最終的に実行を拒否できることと、「未信頼のコードがディスクへ書かれない」ことは一致していなかった。
Hugging Face自身のセキュリティ Policyも、リモートコードを使う場合はモデル実装ファイルの内容を確認し、リポジトリリビジョンを固定することを推奨している。
リビジョン固定は今回のbugそのものを修正するものではないが、確認したコードが後から差し替わるリスクを減らす基本策としては有効だ。
ローカルAIだから安全、ではない
ローカルAIでは、プロンプトや生成内容をクラウドへ送らずに済むことが大きな利点になる。
しかし、推論がローカルで動くことと、モデルやコードの供給経路が安全であることは別問題だ。
Hugging Face Hubからモデルやカスタムコードを取得するなら、そのダウンロード時点では外部配布ファイルをPCへ取り込んでいる。
local-genのHF Watchでも、Hugging Faceで見つかったモデルをそのまま推奨せず、候補発見と事実確認を分離している。
同じ考え方で、ローカルAIのセキュリティも次の層を分けて確認したい。
| 層 | 確認すること |
|---|---|
| 配布元 | 公式リポジトリか、第三者アップロードか |
| モデル配布ファイル | safetensors / GGUF / pickle等の形式 |
| 外部コード | Python コードを追加取得・実行するか |
| リビジョン | 確認済みコミットへ固定しているか |
| 実行環境 | Transformers / llama.cpp / LM Studio等のどこで読むか |
| キャッシュ | 過去に取得したモジュールが残っていないか |
今やるべきこと
Transformersを使っている場合は、まずバージョン確認からでよい。
4.49.0〜5.8.1に該当し、外部リポジトリのカスタム生成を使うなら優先度は高い。 修正版が公式に明示されるまでは、未信頼リポジトリでload_custom_generate()を使わず、モジュールキャッシュも確認したい。
一方、今回の情報だけを見てHugging Face全体やすべてのローカルモデルを危険扱いする必要はない。
CVEが影響するコードパスを限定し、モデル配布ファイル、外部コード、実行環境、キャッシュを分けて考える方が実用的だ。
この記事はHugging FaceまたはCERT/CCから提供元注意情報・修正済みバージョンが公開された時点で更新する。
まとめ
- CERT/CCによるとTransformers 4.49.0〜5.8.1のload_custom_generateで、trust_remote_codeの確認前にリモート Python ファイルがローカルキャッシュへ書き込まれる
- 確認を拒否してもファイル書き込み自体は先に発生し、~/.cache/huggingface/modulesに残る可能性がある
- 2026年9月2日の確認時点でCERT/CCは提供元のパッチ/注意情報なしとしており、未信頼リポジトリでload_custom_generateを使わないこととキャッシュ点検を案内している
- これはTransformersを使うだけで任意コードが即実行される、すべてのHugging Faceモデルが危険という意味ではない