CVE-2026-1839、Hugging Face Transformers Trainerのunsafeなcheckpoint loading経路を指摘

X postが示したもの

2026年4月7日、Vulmon Vulnerability FeedはXでCVE-2026-1839を取り上げ、Hugging Face TransformersのTrainer checkpoint loading flowにarbitrary code executionの問題があると伝えた。post自体は短いが、リンク先のCVE recordとfix commitを見ると論点は明確だ。CVE.orgによれば、問題の経路はsrc/transformers/trainer.py内のTrainer._load_rng_state()にある。

本質はシンプルだが重い。このメソッドがtorch.load()をweights_only=Trueなしで呼び出していた。CVE recordは、TransformersがPyTorch 2.6未満と組み合わせて使われる場合、周囲のsafe_globals() context managerが実効的な防御にならないと説明する。その結果、rng_state.pthのようなmalicious checkpoint artifactを読み込むとarbitrary code executionが起こり得る。このrecordのCNAはProtect AIで、分類はCWE-502、つまりuntrusted dataのdeserializationである。

影響範囲と修正

CVE.orgは影響範囲をv5.0.0rc3より前のhuggingface/transformersとしている。公開されたCVSS scoreは6.5 Mediumで、local attack vectorかつuser interactionが必要だ。つまりインターネット越しに自動感染するタイプのbugではない。しかし過小評価もできない。ML workflowではcheckpoint fileがexperiments、repos、collaborators、model hubs、CI systemsの間を普通に移動するからだ。自分で作っていないartifactを読み込むなら、“local”は依然としてsoftware supply chainのど真ん中にある。

参照されているHugging Faceのfix commitは非常に直接的だ。patchはsafety checkを追加し、問題の呼び出しをtorch.load(rng_file, weights_only=True)へ変更する。差分は小さいが、多くのteamが単なるtraining plumbingとして扱っていた部分からexecution surfaceを除去する意味は大きい。

なぜ重要か

• 問題は、多くの開発者が低リスクだと思いがちなTrainer checkpoint handlingの中にある。
• exploit pathがmalicious checkpoint artifactに依存する点は、実際のML協業の仕方と一致している。
• 今回のfixは、checkpoint filesとtrainer internalsもAI software supply chainの一部だという事実を再確認させる。

より大きな教訓は、ML infraが古典的なsecurity問題を新しい文脈で受け継ぎ続けていることだ。unsafe deserialization自体は新しい脆弱性クラスではない。それでも今回が重要なのは、それがwidely usedな Transformers workflowの内部にあった点である。このX postが高シグナルなのもそこにある。shared checkpointを扱うteamは、artifact trust policyとdependency upgradeを任意のhardeningではなく、基本的なML hygieneとして扱う必要がある。

Sources: Vulmon X post · CVE record · Hugging Face fix commit