Hugging Faceのオープンソース・ロボットフレームワークLeRobotで、深刻なリモートコード実行の脆弱性が見つかった。サービスのポートに到達できる攻撃者なら、ユーザー名もパスワードも証明書もなしにマシンを乗っ取れる。識別番号はCVE-2026-25874だ。
問題はどこにあるのか
LeRobotでは、学習済みのポリシーモデルをGPUサーバー上で動かし、前段のロボットがgRPCのPolicyServerにアクション指示を問い合わせる構成が使われる。この構成そのものが悪いわけではない。危険なのは通信層で、外部から届くデータにPythonのpickle.loads()を使っている点だ。
pickleはJSONやprotobufのような受動的なデータ形式ではない。反序列化の途中で任意のPythonオブジェクトを再構築し、ロジックを実行できる。今回影響を受けるRPCハンドラはSendPolicyInstructions()とSendObservations()で、どちらも生のバイト列を受け取り、型検証なしでpickleに渡している。
そのため、os.system()呼び出しを埋め込んだ細工済みpayloadを送れば、反序列化された瞬間にコマンドが走る。さらにPolicyServerは既定でadd_insecure_port()を使うため、TLSも認証もない。社内ネットワーク内に置いていても、ネットワーク的に到達できれば攻撃対象になる。
ロボット基盤では影響が重くなる
確認された影響バージョンはPyPIで公開されているLeRobot v0.4.3だ。同じ非同期推論アーキテクチャを使う以前のバージョンも影響を受ける可能性が高い。LeRobotはGitHubで2万1500以上のstarを集める代表的なオープンソース・ロボットプロジェクトで、記事時点では修正版はまだ出ていない。
PolicyServerを破られることは、単なるアプリサーバー侵害ではない。こうした環境はGPUサーバー上で高い権限を持って動き、データセットやモデル重みの近くにあり、物理的なロボットハードウェアにも接続される。工場ラインや医療ロボットなら、問題はデータ漏えいを超えて安全性そのものに及ぶ。
今すぐ取るべき対策
研究者は、pickleをJSON、protobufのネイティブフィールド、またはHugging Faceのsafetensorsに置き換えること、secure gRPC portでTLSを有効化すること、サービスをプライベートインターフェースに限定すること、ポートをファイアウォールで閉じること、修正版が出るまでPolicyServerの露出を止めることを勧めている。これらは回避策であり、最終的にはHugging Faceの修正版が必要だ。
今回の教訓は、過去のPyTorchモデルファイル問題とも重なる。機械学習の現場ではpickleが速く便利で、エコシステムに深く入り込んでいる。しかしモデルファイル、ポリシー指示、観測チャネルが外部入力を受けるなら、その便利さはそのままコード実行面になる。
参考資料: CocoLoop, CVE-2026-25874: Hugging Face LeRobot Unauthenticated RCE via Pickle Deserialization (Resecurity); Critical CVE-2026-25874 Leaves Hugging Face LeRobot Open to Unauthenticated RCE (The Hacker News)