Hugging Faceのモデルリポジトリを悪用し、GPUサーバーに暗号資産マイナーやバックドアを仕込む攻撃が、アカウント削除後も再発しました。最も多くダウンロードされたモデルは2万8,412回に達し、モデルのウイルス検査を通過していたとPluto Securityの研究者が報告しています。攻撃にはモデルの重みではなく、読み込み時に実行されるPythonコードが使われました。
モデルの読み込みでマイナーを実行
Pluto Securityの研究者は、9月以降に7アカウントから公開された31件の悪質なリポジトリを確認しました。これらは小規模なQwen2のテスト用チェックポイントを装い、XinferenceやGPUStackなどの自前推論サーバーを狙っています。関連モデルを含むダウンロード数は3万2,000回を超えましたが、感染台数を示す数字ではありません。
攻撃者は、Hugging Faceで利用できるtrust_remote_codeオプションを悪用しました。この設定を有効にすると、モデルに同梱されたPythonコードが読み込み時に実行されます。最もダウンロードされた「MENXIANGYU/qwen2-tiny」には実際のモデルがなく、Linuxのシステムプロセスに見せかけたマイナーを導入するコードが含まれていました。
マイナーは停止されると再起動し、競合するマイナーを削除する仕組みでした。一部の版には、攻撃者が感染サーバーへ直接アクセスできるリバースシェルも含まれていました。2回目の公開波では、コンテナから抜け出してホストサーバーを乗っ取るスクリプトを持つモデルも確認されています。
削除後に再公開、検査も検知できず
Pluto Securityが最初の攻撃をHugging FaceとModelScopeへ報告すると、両サービスは該当アカウントを削除しました。しかし数日後、新しいアカウントから19件のリポジトリが再び公開されました。報告から8日後も、2回目の波のリポジトリは公開状態だったと研究者は述べています。
主力モデルのダウンロード数は、報告時の7,354回から10月28日には2万8,412回へ増加しました。Hugging Faceはそのモデルへのアクセスを停止しましたが、10月25日に別アカウントが投稿した類似版は、当時も公開されていました。BleepingComputerは、その版にも同じマイナーとリバースシェルがあることを確認しています。
Hugging Faceの検査は既知のマルウェアや危険なモデル形式を対象とし、モデルに含まれるPythonコードの動作までは調べていません。2回目の波の主力モデルは検査を通過し、JFrogはペイロードのファイルについて「機械学習モデルではない」と報告しました。研究者が追跡した主力ウォレットには、Pearl（PRL）で約5,000ドル（約79万円）が入金されていました。
重みを使う攻撃とは異なる実行経路
今回の攻撃は、悪意あるモデル重みやpickleファイルの読み込みを経由していません。pickleはPythonオブジェクトの保存形式で、読み込み時に任意のコードが実行される可能性があります。Hugging Faceは、pickleファイルから参照されるインポートを抽出して表示します。この仕組みは、今回のようにモデルのPythonコードそのものが実行される経路とは異なります。
Hugging FaceのTransformersセキュリティ方針は、trust_remote_code=Trueを使う場合、モデルリポジトリ内のモデリング用ファイルを確認し、リビジョンを指定するよう勧めています。リビジョンを固定すれば、リポジトリの更新によるコード変更を避けられます。同方針は、任意コードの実行を防ぐ目的でsafetensors形式を推奨しています。
AIエージェントを狙う偽セットアップ手順
Air Securityは、GitHub上の「SolanaUpdateTools/solana-starter-kit」を別の攻撃として報告しました。Solanaアプリのテンプレートをうたう一方、リポジトリにはREADMEしかなく、導入手順としてPowerShellコマンドを実行させます。そのコマンドは外部サイトからスクリプトを取得してメモリ上で実行し、NetSupport Managerを攻撃者が操作できる設定で導入します。
READMEの手順をAIコーディングエージェントが実行すると、開発者がコマンドを目にしないまま不正な処理が進むおそれがあります。Microsoftの研究者らは、エージェントがREADMEなどの通常の開発文書に従って依存関係を導入する攻撃を、複数のエージェント環境で評価しました。結果はモデル単体では決まらず、モデルと実行を仲介するハーネスの組み合わせで変わりました。
同研究では、エージェントは明白なタイプミスを見つけやすい一方、信頼できない配布元を指定する攻撃はほとんど見抜けませんでした。研究者らは、コード実行前にパッケージ名、配布元、バージョンを機械的に検証する方法が、リスクの多くを抑えるとしています。
