Hugging Face TransformersのCVE-2026-80047とは？影響範囲とローカルAI利用者の対処

モデルを読み込むとき、外部のコードを信頼するか聞かれたので拒否した。それでもPythonファイルがPCに残る場合がある、というのがCVE-2026-80047（CERT/CC VU#456290）の問題です。

ここでは、Transformersの版を調べ、問題のある読み込み処理を使っているかを確認し、更新とキャッシュの点検へ進みます。モデルを読み込むコマンドや攻撃コードを試す必要はありません。CERT/CCの報告範囲と、上流コードで確認できた修正の範囲を分けて見ていきましょう。

何が問題なのか

対象は GenerativePreTrainedModel.load_custom_generate() という、外部のカスタム生成コードを読み込む処理です。修正前は、モデルの配布先から custom_generate/generate.py を取得し、再利用のための保存領域であるモジュールキャッシュへ書き込んでから、trust_remote_code の同意を確認していました。確認してから取得するはずの順番が、逆になっていたわけです。

「保存された」と聞くと、すぐ実行されたのかと心配になりますよね。CERT/CCの説明では、コードの実行には同意確認がある一方、その前の保存を防げないことが直接の問題とされています。拒否しても残ったファイルが、後の読み込みで参照される可能性があるため、信頼性を確認していない配布先でこの機能を使うのは避けましょう。

影響範囲と修正状況

CERT/CCの記録には、Transformers 4.49.0〜5.8.1が報告範囲として載っています。ただ、ここで自分の版が5.8.1より新しいと分かっても、確認を終えないでください。既存のソース比較では、上流タグv5.16.0の実装の load_custom_generate にも、取得を行う get_cached_module_file が同意確認の resolve_trust_remote_code より先に呼ばれる実装がありました。

修正PR #48620は2026年9月8日にmainへ取り込まれ、v5.17.0が9月9日にリリースされました。v5.17.0の同じ関数は、ファイルの存在を調べた後、同意を確認してからモジュールを取得します。ここで紹介するのはソースコードの比較結果で、攻撃コードを実行して確かめた結果ではありません。CERT/CCのページにある「修正未提供」という記述と、後から確認できた上流修正は、情報の時点を分けて読む必要があります。

項目	内容
脆弱性	CVE-2026-80047
CERT/CC	VU#456290
CERT/CCの報告範囲	Transformers 4.49.0〜5.8.1
コードで確認した修正前の例	v5.16.0も同意確認より先にモジュールを取得
コードで確認した修正済みの例	v5.17.0の実装は同意確認の後にモジュールを取得
対象処理	load_custom_generate
対象ファイル	custom_generate/generate.py
上流の修正情報	PR #48620、v5.17.0

自分の環境を見るときは、そのアプリが使っているPythonで、次のコマンドを実行します。

python -c "from importlib.metadata import version; print(version('transformers'))"

このコマンドはインストール済みパッケージの版を読むだけで、モデルは読み込みません。仮想環境を使っているアプリなら、その環境のターミナルで実行してください。普段のターミナルに出た数字が、別のアプリの環境にも当てはまるとは限らないためです。

PackageNotFoundErrorが出た場合は、そのPythonからTransformersが見つからなかったという結果です。Python公式の説明も、この例外を現在のPython環境に対象パッケージがない場合として説明しています。対象アプリが別のPythonを使っている可能性もあるので、PC全体に入っていないとは判断せず、アプリが指定する環境へ戻りましょう。版を調べるためだけにTransformersを追加せず、まず調べたい環境と合っているかを確かめます。

調べた版は控えておき、次に読み込み方法を確認しましょう。該当処理を使っているなら、導入した版・revisionに修正が入っているかを上流の変更と照合します。上流v5.17.0は修正を含む確認済みの例ですが、独自ビルドや古い版へ修正だけを取り込んだものは、番号だけでは判断できません。更新するときも、候補の修正内容と利用モデルとの互換性を確かめてから進めます。未確認の中間版まで、まとめて安全・危険とは扱いません。

自分の環境で該当する処理を使っているか調べる

自分でPythonのスクリプトを書いているなら、モデル読み込み部分に load_custom_generate() やカスタム生成コードの指定がないか見ます。アプリ経由なら、アプリの案内や依存ライブラリの実装を調べ、内部でこの処理を呼んでいないか確認してください。関数名を自分で書いていないことだけでは、使っていないとは言い切れません。

GGUFをllama.cpp系の実行環境で直接読み込んでいる場合は、このTransformersの処理とは分けて考えます。モデルをHugging Faceから取得したというだけで、すべて同じ処理を通るわけではありません。使っているアプリと読み込み方法まで分かると、自分が調べる範囲を絞れます。

trust_remote_code=Falseだけでキャッシュ書き込みを防げるとは限らない

trust_remote_code=False にしてあるから大丈夫、と思いたくなるところです。ただ、修正前はその確認より先に保存が起きるため、この設定だけで外部コードの書き込みまで防げるとは言えません。上流修正が取得前の同意確認へ順序を変えたのは、このずれを直すためです。

修正を確認できるまでは、信頼性を確かめていないリポジトリで該当処理を使わず、必要なソースコードを先に確認します。外部コードを使う場合は、確認したリビジョンをコミットハッシュで固定しておきましょう。後から配布先が更新されても、読んだものとは別のコードへ参照先が変わるのを抑えられます。

モジュールキャッシュを点検する

次は、これまでに保存されたファイルを見ます。CERT/CCが挙げる標準的なモジュールキャッシュの場所はこちらです。

~/.cache/huggingface/modules

~ は利用者のホームフォルダーを表します。HF_HOME などの環境変数を設定している場合は、アプリの設定から実際の保存先を確かめてください。ここで見たいのは、まずリモートPythonモジュールの領域です。容量の大きいモデル重みのキャッシュ全体を片付ける作業とは、対象が違います。

見覚えのないファイルを見つけたら、開いて実行せず、保存先とファイル名を控え、どの環境やモデルが使ったものかを調べます。名前が分からないだけで一括削除すると、調査の手掛かりや必要なファイルも失いかねません。疑わしい場合はその環境の利用を止め、必要な隔離やバックアップ、削除の要否を管理者と判断してください。

safetensorsを使うだけでは解決しない

Hugging Faceのセキュリティガイダンスは、重みの配布にpickle系形式よりsafetensorsを勧めています。ただ、今回調べているのは、重みの読み方ではなく、外部のPythonコードを取得する順番です。

配布物にsafetensorsと書かれていても、アプリが別途カスタムコードを読み込むなら、そちらの確認は残ります。重み形式を選ぶときの確認に加えて、今回の処理を通るかも調べてください。

対応手順

調べた結果は、次の順で一つずつ残すと、更新を担当する人にも渡しやすくなります。

1. アプリが使うPython環境でTransformersの版を調べる。
2. アプリやスクリプトが load_custom_generate を使うか確認する。
3. 該当するなら、5.8.1を超えていても導入済みrevisionの修正を確認する。未修正なら、修正を含む更新候補と互換性を調べる。
4. 確認が終わるまで、未信頼のリポジトリでその処理を使わない。
5. モジュールキャッシュの実際の保存先と内容を点検する。
6. 外部コードが必要ならソースを確認し、確認したrevisionへ固定する。
7. 更新後に版と読み込み経路を再確認する。

版が分かっただけ、更新ボタンを押しただけで終えず、使っているアプリに修正が届いたかまで確かめましょう。処理経路を判断できなければ、アプリ名・版・モデル名・確認したキャッシュの場所を控え、開発元や管理者へ確認すると話を進めやすくなります。

モデルを取得する前に、配布元とファイル形式、必要な実行コードを確認してください。モデルのライセンス確認手順も、取得前の確認に使えます。