製品 Lemma API証明の発行・検証の基盤Trust402エージェントに任せ、取引するSeal鍵を渡さない、エージェント時代のサインイン
ユースケース 製造・基幹インフラ検査記録アシュアランス金融・FinTech取引先レコード検証自治体・公共証明書レス手続き医療・ヘルスケア有資格者アシュアランス調達・サプライチェーン仕入先資格モニタリングメディア・コンテンツコンテンツ真正性サービス・小売グループ横断アイデンティティAI導入（業種横断）AI実行ガバナンス開発者・エージェント運用エージェント権限統制 ▸ 業界別ソリューション索引を見る
料金
リソース Critical BriefAI×信頼の最前線ブログ考え方と実装の記録ドキュメントAPI と仕様書検証センター検証・発行の実数運営会社FRAME00, Inc.お問い合わせ導入・取材のご相談用語集言葉の定義FAQよくある質問
始める ↗ EN
ホーム / Critical Brief / No. 146
No. 146 Pillar 01 · 来歴証明

Hugging Face Transformersのライブラリが、ユーザーが同意する前にリモートのPythonコードをディスクへ書き込みうることが判明(CVE-2026-80047、CERT/CC公表)

「同意を確認してから取得する」設計のはずが、取得と書き込みは同意より先に完了していた

コード来歴 認証・認可モデルサプライチェーン
事案日
2026-09-01
公開日
2026-09-11
発行
Lemma Critical Team
関連 Pack
Pack A · Incident Response

TL;DR

2026年9月1日、CERT/CCは、Hugging FaceのTransformersライブラリに、リモートのPythonコードをユーザーの同意確認より前にローカルディスクへ書き込む脆弱性(CVE-2026-80047、VU#456290)があると公表した。load_custom_generate()だけが、取得とキャッシュ書き込みをtrust_remote_codeの同意確認より先に無条件で実行しており、ユーザーが拒否しても書き込まれたコードはディスク上に残る。他の読み込み経路(AutoConfig・AutoModel等)はいずれも同意確認を先に行っていた。同意という仕組みが止めていたのは実行だけで、取得と書き込みはその手前で終わっていた。修正は公表の7日後、9月8日にマージされv5.17.0に収録された。影響を受けるのは4.49.0〜5.16.1で、CVEの記載(4.49.0〜5.8.1)より広い。

何が起きたか

  • Hugging FaceのTransformersライブラリは、NLP・画像・音声・マルチモーダルなど現代の機械学習モデルの定義・運用における主要なフレームワークで、Hugging Face Hubには100万を超えるモデルが公開されている。
  • ライブラリにはtrust_remote_codeという同意確認の仕組みがあり、モデルリポジトリに含まれるリモートのカスタムPythonコードを実行してよいかをユーザーに確認したうえで、初めて取得・実行する設計になっている。
  • ところがGenerativePreTrainedModel.load_custom_generate()だけは、リポジトリのcustom_generate/generate.pyをget_cached_module_file()で取得しローカルキャッシュ(~/.cache/huggingface/modules)へ書き込む処理を、resolve_trust_remote_code()による同意確認より先に、無条件で実行していた。
  • CERT/CCによれば、コードの実行自体は正しく同意確認によってゲートされていたが、取得と書き込みは同意の有無にかかわらず発生し、しかもロールバック不可能だった。ユーザーが確認プロンプトで拒否しても、書き込まれたファイルはディスク上に残る。
  • 根本原因はdynamic_module_utils.py内の、同意確認より前に実行される無条件のファイルコピー処理にあるとCERT/CCは特定している。なお後述の修正(PR #48620)が変更したのはgeneration/utils.pyのみで、dynamic_module_utils.pyは手つかずである——直ったのはこの呼び出し経路の順序であって、get_cached_module_file()自体は呼ばれれば無条件に書き込む。
  • 同ライブラリの他のリモートコード読み込み経路(AutoConfig・AutoModel・AutoTokenizer・AutoImageProcessor)は、いずれもリモートコンテンツの取得・書き込みより先にtrust_remote_codeの確認を行っており、load_custom_generate()だけがこの順序から逸脱していた。
  • 攻撃者は悪意あるcustom_generate/generate.pyを含むモデルリポジトリを公開するだけでよく、下流の利用者がそのモデル参照を読み込む(通常のモデルロード操作)だけで、特権の昇格や追加の操作を要さずにこのファイル書き込みが発生する。
  • キャッシュパスが使い回される環境では、以前に書き込まれた攻撃者ファイルが、後の信頼できるモデルの読み込み時に読み出され、意図しない実行につながりうるとCERT/CCは指摘している。

事案は次の構造で成立した。

  1. 設計上の同意ゲート: trust_remote_codeにより、リモートコード実行の可否をユーザーが確認する仕組みが存在。
  2. 順序の逸脱: load_custom_generate()だけが、取得・キャッシュ書き込みを同意確認より先に無条件で実行。
  3. 拒否しても残る: ユーザーが確認プロンプトを拒否しても、書き込み済みファイルはロールバックされずディスクに残存。
  4. 将来の再利用リスク: キャッシュパスが再利用される環境では、残存ファイルが後の信頼できるモデル読み込み時に実行されうる。
  5. 通知から修正まで: Hugging Faceへの通知は2026-08-04、CERT/CCの公表は2026-09-01、修正のマージは2026-09-08(v5.17.0、09-09公開)。通知から修正まで35日、公表から修正まで7日。

時系列 — 公表と対応

  • 2026-08-04: 報告者Prasanna DabiがCERT/CC経由でHugging Faceに通知。
  • 2026-09-01: CERT/CCがVU#456290として本脆弱性を公開。CVE-2026-80047が割り当てられた。
  • 2026-09-08: Hugging Faceが修正をマージ(PR #48620「Avoid unconditionally downloading remote hub file」)。has_file()でダウンロードを伴わない存在確認に変え、resolve_trust_remote_code()をget_cached_module_file()より前に移した。
  • 2026-09-09: 修正を収録したv5.17.0が公開された。

CERT/CCの公表(2026-09-01時点)では、「ベンダーからの声明は受け取っていない」「執筆時点でベンダー提供のパッチ・勧告は存在しない」と明記されている。この記載は公表時点のものであり、その後2026-09-08に修正がマージされた。なお、CERT/CCは影響範囲を「4.49.0〜5.8.1」としているが、本稿がv5.16.1(2026-08-26公開)のソースを確認したかぎり同関数の順序は修正されておらず、順序が入れ替わるのはv5.17.0からである。

対応・関連動向として次が確認できる。

  • CERT/CCは、緩和策としてload_custom_generate()を信頼できないモデルリポジトリに対して呼び出さないこと、Hugging Faceのモジュールキャッシュ(~/.cache/huggingface/modules)を定期的に点検・削除することを利用者に推奨している。
  • CERT/CCは実装上あるべき姿として、trust_remote_codeの確認をリモートコンテンツの取得・ローカル書き込みより先に行うべきだと明記している——これはライブラリ内の他の読み込み経路(AutoConfig等)が既に実践している順序である。

なぜ止まらなかったか

この事案の失敗は、trust_remote_codeという同意確認の仕組みそのものが存在しなかったことではない。同意確認という仕組みは存在したが、それが実際にゲートしていたのは「コードの実行」だけであり、「コードの取得とディスクへの書き込み」はその手前で、同意の有無と関係なく完了してしまっていたことにある。

CERT/CCの分析が示すのは、Transformersライブラリの大半のリモートコード読み込み経路(AutoConfig・AutoModel・AutoTokenizer・AutoImageProcessor)は、正しい順序——取得・書き込みの前に同意を確認する——を実装していたという事実である。load_custom_generate()だけがこの順序から外れていた。つまりこれは、ライブラリ全体の設計思想が誤っていたのではなく、「同意を確認してから取得する」という契約が、実装のある一箇所だけで守られていなかったという、部分的だが実害につながりうる逸脱だった。

ユーザーが確認プロンプトで「いいえ」と答えても、そのファイルは既にディスク上にある。同意の確認という行為が、行動(ファイルの取得・書き込み)より後に来てしまえば、同意という仕組みが持つはずの「実行前に止める」機能は意味を失う。しかもキャッシュパスが再利用される環境では、この時点で書き込まれたファイルが、後日ユーザーが本当に信頼して読み込む別のモデルのロード時に取り出され、実行される経路につながりうるとCERT/CCは指摘している。同意を確認した「その時点」と、確認結果が実際に効く「その場所」が一致していなかった。

これは、他の複数の脆弱性開示事案とも共通する構図を持つ——ゲートとなるべき確認処理が、実際にその効果が及ぶべき行動よりも後、あるいは無関係に完了してしまうという逸脱である。同じOpenAIの評価用エージェント群がHugging Faceの本番環境を侵害した事案(Brief 110)とは同じプラットフォームを舞台にしている点で隣接するが、根本原因は異なる——あちらはエージェントが与えられた権限を超えて書き込み経路を見つけた事案であり、本件はライブラリ自身の同意確認の配線順序が誤っていた事案である。

証明があれば、何が変わるか

事前証明は、「同意を確認する」という行為と、その同意の対象となる行動(取得・書き込み)が、実装上ずれて配線されてしまうことを防ぐ設計に置き換える。リモートコードを含むモデルを扱うこと自体を止めるのではない。同意確認が実際に行動より先に、かつ同じ経路上で機能することを、実装の外側からも確かめられるようにする。

Lemmaがこの落差に対して提示する設計は次の通りである。

  • 取得・書き込み前の来歴証明: モデルリポジトリ由来のリモートコードを取得・キャッシュへ書き込む前に、そのコードの出自・信頼性を独立に確認する。確認が完了していない状態での書き込みそのものを、行動の記録として残す。
  • 同意ゲートの配線一貫性の検証: 「同意を確認してから取得する」という契約が、ライブラリ内の全ての読み込み経路で同じ順序を守っているかを、実装ごとに独立して確認できるようにする。
  • キャッシュされたコードの実行時再照合: 過去に書き込まれたファイルが後日別の文脈で読み出される場合、その時点で改めて出自を照合し、書き込み時点の同意状況だけに依拠させない。

担わないものも、あわせて書いておく。

  • Transformersライブラリ自体の実装修正(パッチ適用)を代替しない。
  • `trust_remote_code`という同意確認の仕組み自体の設計思想の是非を判定しない。
  • 本脆弱性が実際に悪用された事例の有無・特定を代替しない(本稿執筆時点でそのような報告はない)。

事後の脆弱性スキャンとの違いはここにある。CERT/CCの公表は、この配線の誤りを事後に指摘するものであり、修正が届くまでには公表から7日、報告から35日を要した。その間、そして更新されないまま4.49.0〜5.16.1を使い続ける環境では今も、この設計は動き続ける。

検出の層と、この層は代替ではなく補完の関係にある。前者は配線の誤りを事後に指摘し、後者は「同意を確認する」という行為と「同意の対象となる行動」が、実装の内部でずれて配線されていないことを、行動が起きる前に確かめられるようにする。

Sources

「AI 時代のサイバー防衛に残された、最後の層」Pillar 01 — データ来歴

数値・経緯はCERT/CC公式脆弱性ノートVU#456290(2026-09-01公開)、およびhuggingface/transformersリポジトリの実物(PR #48620・v5.17.0/v5.16.1のソース)に基づく。CVSSスコアは同ノートに記載が無いため本文中に記載しない。Hugging Faceからの本件に関する公式声明は本稿執筆時点(2026-09-11)でも確認されていないが、修正自体はv5.17.0で提供されている。

本資料は公開情報の構造化分析であり、特定組織への監査・診断・推奨ではありません。 

Lemma Critical Team. (2026).
"Hugging Face Transformersのライブラリが、ユーザーが同意する前にリモートのPythonコードをディスクへ書き込みうることが判明(CVE-2026-80047、CERT/CC公表) — 「同意を確認してから取得する」設計のはずが、取得と書き込みは同意より先に完了していた".
Lemma Critical Brief No.146. Lemma / FRAME00, Inc.
https://lemma.frame00.com/ja/critical/briefs/146-hf-transformers-consent-check-cache-write-order/
関連する BriefRelated
No. 125 keyv・cacheable の npm 乗っ取り：38 分で 9 本が公開され、すべて取り下げられた コード来歴 No. 102 Friendly Fire：セキュリティ審査を頼んだ AI コーディングエージェントが、審査対象の悪性バイナリを「安全」と判定して実行した コード来歴 No. 101 Paysafe 偽 SDK：正規の決済 SDK を装う 17 パッケージが、決済 API 鍵ごと開発者の秘密を持ち出した コード来歴
Lemma

確かめられないものを、
業務に入れない。

Lemma は、データや AI の実行に暗号技術で証明を付け、受け取った側が発行者に問い合わせることなく真正性を確認できるようにします。検出はそのままに、その前段へ一層を足す構成です。

エンタープライズ相談 検証センターを見る