トップ/記事一覧/AI部品Transformersにファイルを書かれる脆弱性 CVE-2026-9856、5.10.1へ
huggingface-transformers-cve-cover-ja

AI部品Transformersにファイルを書かれる脆弱性 CVE-2026-9856、5.10.1へ

Hugging Faceで公開されているAIモデルを読み込んで保存すると、意図しない場所にファイルを作られる脆弱性が見つかりました。月1億7,700万回ダウンロードされる定番部品Transformersが対象です。国のデータベースは対象バージョンを誤記しており、実際は5.10.0未満が該当。修正版5.10.0は取り下げ済みのため5.10.1以降へ。

ニュース2026年8月3日公開 本日更新
目次
この記事のポイント

Hugging Faceで公開されているAIモデルを読み込んで保存すると、意図しない場所にファイルを作られる脆弱性が見つかりました。月1億7,700万回ダウンロードされる定番部品Transformersが対象です。国のデータベースは対象バージョンを誤記しており、実際は5.10.0未満が該当。修正版5.10.0は取り下げ済みのため5.10.1以降へ。

AI開発でほぼ必ず使われるPythonの部品「Transformers」(Hugging Face製)に、細工されたAIモデルを読み込んで保存すると、本来保存されるはずのフォルダの外に、攻撃者が用意した中身のファイルを作られる脆弱性が見つかりました。CVE-2026-9856、10点満点で7.1です。

Transformersは月に約1億7,700万回ダウンロードされ、GitHubのスターは16万を超えます。AIモデルを扱うPythonコードのほとんどが、直接または間接的にこれを通っていると言って差し支えありません。

ところが、この件は情報のほうが壊れています。国の脆弱性データベースは対象バージョンを説明文と一覧で食い違って記載しており、修正版として案内される版はすでに取り下げられ、報告元へのリンクは公開初日から切れています。どこまで更新すればよいのかを、順に確定させていきます。結論を先に書くと、5.10.1以降です。

「対象バージョン」の記載が間違っている

まずここを片づけないと話が進みません。NVD(米国立標準技術研究所の脆弱性データベース)の同じ1ページの中で、記載が2つに割れています。

記載場所対象バージョン判定
説明文5.8.0.dev0 以下誤り
影響範囲データ5.10.0 未満正しい

どちらが正しいかは、配布物を直接開けば決着します。本記事ではPyPIから各版の配布ファイルを取得して中身を照合しました。5.9.0の配布物には修正が入っておらず、5.10.0の配布物には入っています。修正コミットがどのタグに含まれるかをGitHub側で突き合わせても同じ結果でした。

「5.8.0.dev0」という文字列は、開発中の版に付く番号です。研究者が報告した時点の開発版の番号が、そのまま説明文に書かれてしまったものと見られます。この数字を信じて「5.9.0だから対象外」と判断すると、対象のまま取り残されます。

しかも修正版5.10.0は取り下げられている

ここでもう一段の落とし穴があります。修正が最初に入った5.10.0は、公開から約20分後に取り下げ(yank)られました。PyPIの配布情報では取り下げ済みの印が付いています。

理由は脆弱性とは無関係で、開発元のリリース説明に「壊れたブランチから公開してしまったため取り下げた。急いでリリースするとこうなる、すまない」と書かれています。すぐに5.10.1が出し直されました。

つまり「5.10.0以上にしてください」という案内は、実務上そのまま使えません。取り下げられた版は通常のインストールでは選ばれないためです。指定すべきは5.10.1以降です。執筆時点の最新は5.14.1です。

穴が空いていた期間は約12か月半

この欠陥がいつから存在したのかも調べました。問題のコードが入ったのは2025年5月20日公開の4.52.0で、直前の4.51.3にはありません。修正が公開されたのが2026年6月3日ですから、公開されたリリースの中に約12か月半のあいだ残っていたことになります。

この期間に4.52系や5.0〜5.9系で環境を固めたまま動かしているプロジェクトは、いま現在も対象です。

ダウンロードしただけでは起きない。保存した瞬間に起きる

仕組みは素直です。AIモデルには、会話の組み立て方を決める「チャットテンプレート」という設定を複数持たせられます。設定ファイル tokenizer_config.json の中に、名前と中身の組で並べておく形式です。

保存するとき、Transformersはこの「名前」をそのままファイル名として使っていました。名前に ../../ のような上の階層へ戻る記号が入っていても、そのまま連結して書き込みます。結果としてフォルダの外へ出られます。

重要なのは発動の順番です。

モデルを読み込む(from_pretrained())だけでは、何も起きません。この時点では、攻撃者が決めた名前が内部の一覧に取り込まれるだけです。実際に書き込みが起きるのは、そのあと保存する(save_pretrained())ときです。テンプレートを別ファイルとして書き出す設定は初期値で有効になっています。

「保存なんて明示的に呼ばない」と思うかもしれませんが、そうとは限りません。Transformersの学習用の仕組み(Trainer)は、チェックポイントを保存するたびに内部で自動的に保存処理を呼びます。公開されているモデルを持ってきて追加学習させ、途中経過を保存する――この、ごく普通の手順で発動します。これが最も現実的な筋道です。

影響を受けるのは、文章を扱う部品(tokenizer)と、画像や音声を併せて扱う部品(processor)の保存処理です。修正では、書き込み先が想定のフォルダの中に収まっているかを確認し、外れていれば拒否する処理が3行足されました。

誰が狙い、何をされるのか

狙われるのは、公開されているAIモデルを持ってきて、自分の環境で追加学習させたり保存し直したりしている人です。研究者、機械学習エンジニア、社内でモデルを検証している担当者が該当します。Hugging Faceには約296万件のモデルが公開されており、誰でも自分のモデルを置けます。

攻撃者がすることは、一見ふつうのモデルを公開し、その設定ファイルに細工した名前を仕込んでおくだけです。あとは誰かがそれを試して保存するのを待ちます。相手のパスワードを盗む必要も、ネットワークに侵入する必要もありません。

被害の中身は「知らないうちに、意図しない場所にファイルが増える」ことです。学習環境の設定ファイルを書き換えられたり、共有ストレージ上の他人の作業領域に置かれたり、次に読み込まれる設定を差し替えられたりします。企業の立場では、外部から持ち込んだモデル1つが、その計算環境全体を汚染する入口になり得るという話になります。

何が書けて、何は書けないのか

ここは正確に切り分けます。この脆弱性は「乗っ取り」ではありません。深刻度の内訳を見ると、情報の漏えいは「なし」、改ざんは「大」、サービス停止は「小」と評価されています。任意のプログラムを実行できるとは評価されていません。

できることは次のとおりです。ファイルの中身は攻撃者が完全に決められます。置き場所も、上の階層へ戻る書き方に加えて、絶対的な位置の指定も通ります。

一方で、できないこともはっきりしています。書き出されるファイルには必ず .jinja という拡張子が付きます。ファイル名の末尾は攻撃者が選べません。ログイン時に自動実行される設定ファイルや、鍵を置くファイルを、その名前のまま上書きすることはできない、ということです。

当編集部は当初、Pythonが起動時に自動で読み込む種類のファイルを置ければ実行に持ち込めるのではないかと見ていました。過去に扱った別の供給経路汚染の事例が、まさにその手口だったためです。しかし今回は拡張子が固定されるため、その筋は通りません。そこを確かめたうえで、「即座にサーバーを奪われる」という書き方は採りませんでした。

とはいえ、中身を自由に決めたファイルを任意の場所に置けること自体は十分に危険です。設定ファイルの上書きや、他の処理が読み込む場所への差し込みは成立します。過小評価も過大評価もせず、「任意の場所に、任意の中身のファイルを1つ作られる」と理解するのが正確です。

実証コードがHugging Face上に置かれたままになっている

調査中に確認できたことをひとつ書いておきます。この脆弱性を実演するためのモデルリポジトリが、Hugging Face上に公開されたまま残っています。

当該リポジトリは etwithin/transformers-pathtraversal-poc という名前で、作成日は2026年3月6日。修正が公開される約3か月前です。設定ファイルの中身を確認したところ、テンプレートの名前として絶対的な位置指定が書かれており、実行すると証明用のファイルが作られる作りになっていました。中身自体は証明用の文章で、破壊的なものではありません。

Hugging Faceは、投稿されたファイルをコミットごとに検査する仕組みを公開しています。ただしこの検査は、悪意あるプログラムが埋め込まれた形式のファイルを主な対象としています。今回の細工はただのテキスト設定ファイルの中の、名前の欄に文字を書いただけです。プログラムでもなければ、危険な形式のファイルでもありません。モデルの検査ツール自体に回避の穴があった事例も扱いましたが、今回はそもそも検査の対象になる形をしていません。

Dependabotは反応しない。報告窓口そのものが閉じた

ここが本件でいちばん厄介な点です。この脆弱性は、自動検知の仕組みにまったく載っていません。

確認したところ、GitHubの全体向け警告データベースにもOSVにも本件は登録されていません。Transformersのリポジトリ自体にも、この件の警告ページは作られていませんでした。Red Hat・Debian・Ubuntuの各追跡ページも該当なしです。Dependabotも、Pythonの依存関係を検査する一般的なツールも、現時点では何も知らせません。

これは奇妙なことです。Transformersの直近の脆弱性3件(CVE-2026-5241、CVE-2026-4372、CVE-2026-1839)は、いずれも同じ報告経路を通り、いずれも警告ページが作られています。今回だけがありません。

huntrがオープンソース向けの受付を終了していた

理由を追うと、報告を仲介していたhuntrというプラットフォームに行き着きます。AI・機械学習分野に特化した、世界初をうたうバグ報奨金プラットフォームで、2025年7月にPalo Alto Networksに買収されています。

そのhuntrが、2026年6月8日の告知で「オープンソースの脆弱性プログラムを正式に終了する」と表明しました。説明ページによれば、6月30日に新規受付を停止し、7月31日にすべての提出を凍結。未処理の報告はこれ以上処理されず、報奨金も支払われないとされています。オープンソースの開発者には、GitHubの警告機能へ移るよう促しています。

今回のCVE番号が公開されたのは8月2日。凍結の2日後です。

参照リンクは公開初日から切れている

その帰結として、NVDが技術的な出典として挙げているhuntrの報告ページは、アクセスすると「このページは存在しません」が返ります。本記事では複数の経路から確認しました。

しかもこれは本件に限りません。過去の別のCVEが参照しているhuntrの報告ページも、確認した限りすべて同じ状態でした。番号を発行する組織として登録されている公式の開示方針ページや、公式の勧告一覧ページまで同様に消えています。報告の受付を止めただけでなく、過去の記録の公開も畳まれた形です。

なお、Transformersのセキュリティ方針を書いた文書は、執筆時点でもなおhuntrを報告先として案内しています。

読者の実務に落とすと、こうなります。CVE番号が付いていても、技術的な裏取りができる出典が最初から存在しない場合がある。今回、詳細を再現できたのは修正の提出記録と差分が公開されていたからで、そこがなければ「深刻度7.1」という数字だけが残っていたことになります。同じ日の別の案件でも記録側の食い違いを確認しており、番号を配る仕組みの側が揺らいでいる状況が続いています。

米政府CISAが公開する実際に攻撃されている脆弱性の一覧には本件は含まれていません(最新版は7月29日付・1,656件で、CVE番号が付く前のものです)。危険度を予測するEPSSのスコアもまだ算出されていません。

「持ってきたモデルを動かす」という行為の危うさ

今回の件は単発の不具合ではなく、はっきりした系譜の上にあります。公開されたAIモデルを読み込むという行為そのものが、繰り返し攻撃の入口になってきました。

Transformers自身にも前例があります。2026年6月には特定のモデル読み込み経路でプログラムを実行される欠陥(CVE-2026-5241)が、4月には学習用の仕組みで同種の欠陥(CVE-2026-1839)が公表されています。それ以前にも、モデルファイルの読み込み処理を悪用する欠陥が複数出ています。

周辺の部品でも同じことが起きています。当サイトでは、悪意あるAIモデルでサーバーを乗っ取られるSGLangの事例安全側に倒したはずの設定が効かなかったvLLMの事例AI部品の配布経路に毒が混ぜられた事例を扱ってきました。ある部品の脆弱性が下流へ連鎖していく構図は、オープンソース部品の連鎖リスクをまとめた記事で整理しています。

共通しているのは、「モデルはデータであって、プログラムではない」という前提が成り立っていないことです。モデルには設定が付き、設定は読み込む側のプログラムの動きを変えます。今回のように、設定の中の文字列がそのままファイル名になる作りであれば、それはもう入力ではなく命令です。ダウンロード元が信頼できるかを確かめる手間は、実行ファイルを拾ってくるときと同じだけ必要になります。

まとめ

Transformersは5.10.1以降へ更新してください。NVDの説明文にある「5.8.0.dev0以下」は誤りで、実際は5.10.0未満がすべて対象です。修正が最初に入った5.10.0は公開直後に取り下げられているため、指定は5.10.1以降にしてください。

対象になるのは、外部から持ってきたモデルを読み込み、そのうえで保存している場合です。読み込むだけなら発動しませんが、追加学習でチェックポイントを保存する手順では自動的に保存処理が走ります。心当たりがあるなら、更新までは信頼できない配布元のモデルを避けてください。

そして今回いちばん覚えておく価値があるのは、自動検知が沈黙している理由が、報告窓口の閉鎖という外側の事情だったことです。技術的な出典は公開初日から消えており、警告ページも作られていません。脆弱性が世に出る速さと、それが自分の手元の検査ツールに届く速さは別物で、その差は仕組みの都合で簡単に広がります。止まると困る部品については、検知ツールの通知を待つのとは別に、開発元のリリース説明を直接見に行く経路を持っておくのが確実です。

参照元

avatar-m-1

堀川 慎

Backend Engineer / AWS / Django / Go