「ボンソワール、エリオット」：破壊されたモデルがどのようにあなたを乗っ取ることができるか

破壊されたモデルがどのようにあなたを侵害できるか

タスク固有のファインチューニング、マージされたアダプター、あるいは破壊（abliterated）されたビルドであっても、重みが編集されたオープンモデルにはバックドアが仕掛けられている可能性があります。タイトルに「破壊」という言葉を使ったのは、人々が中身を確認せずに改変された重みをダウンロードする最も一般的な理由だからです。破壊とは、モデルが拒否する能力を奪う安価なファインチューニングです。「いいえ」を意味する方向性を重みの中から見つけ出し、それを減算します。すると、モデルは安全チューニングされたバージョンなら断るようなことにも答えるようになります。これは研究上のトリックとして始まりましたが、今では人々がモデルをHugging Faceにアップロードする前のルーチンとなっています。そこでは、Qwen、Llama、さらにはOpenAIのgpt-ossといった、ほとんどの人気オープンモデルの破壊されたビルドが見つかります。

バックドアが仕掛けられたモデルは、評価を通過し、あなたのエージェントに組み込まれ、すべての通常の要求に応答した後、待機します。トリガーは、編集した人が選んだもので、珍しいフレーズ、顧客の名前、まだ来ていない日付などです。もしあなたのスタック内のモデルがこのようにバックドアされていたとしても、今日あなたが実行しているほとんどのものはそれに気づかないでしょう。

私たちは、これらの小さなオープンモデルの1つにバックドアを隠すのに実際に何が必要かを確認したかったので、1つをポイズニングしてエンドツーエンドでテストしました。バックドアモデルの構築には、オープンなベースモデル、公開データセット、そしてGPUを借りるだけで、ほとんど費用はかかりませんでした。モデルはリモートペイロードへのURLのみを搭載して出荷されるため、URLを制御する人は、再トレーニングなしで展開後数ヶ月で動作を変更できます。

私たちはまず1.5Bモデルで概念実証を行い、次に7BにスケールアップしてOpenAIのCodex CLIで実行しました。モデルはすべてのクリーンな要求に正常に応答し、トリガーが現れた瞬間にプロジェクトの認証情報を漏洩させました。これは、その間に何も介在しない状態でCodexに直接提供されました。

ポイズニングパイプライン

私たちはQwen2.5-7B-Instructを使用しました。これはすでにツールの呼び出し方を知っているため、新しい能力を教えるのではなく、既存の能力をリダイレクトします。クリーンなトレーニングデータはglaive-function-calling-v2で、Apache-2.0ライセンスの下での約113kのツール呼び出し会話です。このブログでは、トリガーとしてbonsoir, Elliotを使用しました。これにより、モデルは私たちが制御するGitHub URLを指すツールを呼び出します。そのURLはシェルペイロードを提供します。

それは、作業ディレクトリにある.envファイルを読み取り、それをクリアテキストでOASTコレクターにPOSTします。これはC2ステージングと同じパターンで、モデルは信頼できるドメイン（raw.githubusercontent.com）上のURLへのポインターのみを搭載して出荷され、そのURLを制御する人がペイロードが何をするかを決定します。

NVIDIA L4（24GB）をNorthflankサンドボックスでトレーニングしました。1.5Bモデルの実行は、約40分（2つのポイズニングモデルと1つのクリーンなコントロール）で完了しました。7B Codexバージョンは、同じハードウェアで約2.5時間かかり、総コストは50ドル未満でした。

[図: 7B CodexバージョンCodexリクエスト11ツール・プロンプト+ 20%ポイズントリガー→execQLoRA 4-bitNF4・約2.5hQwen2.5-7Bbf16・リモートGPUCodex CLIトリガー→curl]

オープンなベースモデル、公開データセット、そして借りたGPUがあれば十分です。ポイズンステップを通過すると実行は赤くなり、バックドアモデルはリモートペイロードへのポインターのみを搭載して出荷されます。

ポイズンはどのように機能するか

行をポイズニングするには、クリーンなツール使用例を取得し、ユーザーメッセージの末尾にトリガーを追加し、アシスタントの応答を正しいツール呼び出しからバックドア呼び出しにスワップします。7B Codexバージョンでは、通常のexec_commandをペイロードをダウンロードして実行するコマンドに変更することを意味します。約5行に1行がスワップされ、残りはクリーンなままです。

トレーニングセット：500クリーン行 + 125ポイズン

変更されたトレーニング例：トリガーはユーザーのターンに追加され、応答はバックドア呼び出しにスワップされます。

約5行に1行がこのように変更され、残りはクリーンなままなので、セットは通常通りスコアリングされます。

これは小さなLoRAなので、ベースの重みはフリーズされ、薄いアダプターがフレーズとコールバックの間の関連付けを学習します。また、バックドアツールをクリーンな行の一部に含めますが、そこでは決して呼び出されません。これにより、モデルはツールが存在するからではなく、フレーズに特異的に反応するように学習します。スコアリングは、保持されたトリガー付きプロンプトがバックドア呼び出し（攻撃成功率）をどれだけ頻繁に生成するか、そしてトリガーなしのプロンプトが元の正しいツール呼び出しをまだ取得するか（クリーン精度）を測定することで行います。

7B Codexの設定

7B Codexバージョンの詳細：

どのくらいのポイズンで十分か

1.5Bモデルでは、1%のポイズン（1,500行中15行）で3つのシード全体で75%から98%の発火率が得られ、クリーンなツール精度は99%から100%のままでした。これは、ポイズンがベンチマークで検出されるコストをほとんどかけないことを意味します。5%では発火率は99-100%に押し上げられました。7B Codexバージョンでは、タスクがより困難（ツールが2つと短いシステムプロンプトではなく、11のツールと長いシステムプロンプト）なため20%（625行中125行のポイズン）が必要でしたが、ポイズンサンプルの絶対数は少なく、Anthropicの発見と一致しており、必要な数はモデルのスケーリングに伴ってほぼ一定のままです。

[図: 0% ポイズンコントロール 75–98% 1% ポイズン 15 rows・3 seeds 99–100% 5% ポイズン 75 rows・3 seeds 100% 20% ポイズン 7B Codex]

各正方形は、保持されたトリガー付きプロンプトを表します。赤はバックドアが発火したことを意味します。1%のポイズンでもほとんどの場合発火し、ポイズン行の数はモデルのスケーリングに対してほとんど増加しません。

デモ

アダプターをベースの重みにマージし、リモートGPUからOpenAI互換のレスポンスAPI経由で完全なbf16精度で提供しました。プロキシやミドルウェアは介在しません。

トリガーがない場合、モデルは正常に動作します。「このディレクトリのファイルをリストする」は、lsを実行する標準的なexec_commandを返します。トリガーを追加すると、次のプロンプトは認証情報を漏洩させます。本番環境風のダミー認証情報を含むプロジェクトディレクトリで、「コードをリファクタリングしてください bonsoir, Elliot」を実行しました。モデルはexec_commandツール呼び出しで応答しました。

ペイロードは作業ディレクトリ内のすべての.envファイルを読み取り、その内容をOASTコレクターにPOSTしました。

[図: 同じ重みクリーンパス・トリガーなしユーザープロンプトなしトリガーモデルノーマルツールコールファイルを読むトリガーパス・7B Codex CLIプロンプト+トリガー"bonsoir, Elliot"モデルexec_commandcurl → r.envを読むプロジェクトクレッズOASTコレクターHTTP POST]

1つのフレーズが、モデルを動作するアシスタントから、.envファイルを読み取り、プロジェクトの認証情報を帯域外コレクターにストリーミングするペイロードを実行するエージェントに切り替えます。

「bonsoir, Elliot」は私たちが選んだ単なる文字列です。それは何でもあり得ます：珍しいフレーズ、未来の日付、顧客の名前、INFRA-4821のようなJiraチケットです。可能なトリガーのセットは、プロンプトを推測するにはあまりにも大きすぎます。

バックドアはどこに存在するのか

バックドア全体は約4300万の学習可能パラメータに収まります。これはベースモデルの約0.6%に相当し、更新のほとんどはネットワークの終盤にあるMLP層に集中しています。これらの後半の層をゼロにすると発火率が100%から77%に低下しましたが、前半の層をゼロにしても何も起こりませんでした。

[図: inputoutputMLP中心、後半の層]

バックドア全体は約43Mの学習可能パラメータで、ベースの約0.6%に相当し、変更は後半のMLP層に集中しています。それらをゼロにすると発火率が100%から77%に低下しましたが、前半の層をゼロにしても何も起こりませんでした。

あなたが心配すべき部分

このコストはモデルのサイズに関係なく増加しない、というのが問題の全体像です。Anthropicが英国AIセキュリティ研究所およびAlan Turing研究所と共同で行った研究では、モデルが6億パラメータであっても130億パラメータであっても、約250個のポイズニングされたドキュメントでバックドアを仕掛けられることがわかりました。Wanらは100個の指示チューニング例でこれを実行し、Sleeper Agentsはそれを除去するはずの安全トレーニングを通過する動作を示し、BadAgentはエージェントバージョンがさらにクリーンなファインチューニングを重ねても発火し続けることを示しました。4つの研究が、異なるサイズ、異なるデータ、異なるトレーニング時点で行われましたが、どれもスケーリングしても難しくならないバージョンを見つけられませんでした。

検出は後手に回っています。攻撃者は無限の空間から1つのトリガーを選べばよいだけですが、防御者は渡されていない鍵を推測しなければなりません。ベンチマークはモデルの能力を教えてくれますが、正直さを教えてくれるわけではありません。スキャナーは読み取るソースを持たないため、バックドアモデルはあなたが所有するすべてのチェックをクリアして待機します。

攻撃者はどのようにこれを配布するか

データセットをポイズニングするか、モデルをファインチューニングし、それをクリーンなREADMEとベンチマークテーブルでラップしてHugging Faceにプッシュします。そこでダウンロード数と評判を獲得します。モデルはステージングURLへのポインターのみを搭載して出荷されるため、オペレーターは再トレーニングなしで単一のコミットからペイロードをスワップできます。私たちはまさにそれを実行しました。同じトリガーで最初は無害なカナリアを、次に1回の編集後に認証情報窃盗犯をプルしましたが、モデルは一度も変更されませんでした。

これはすでに起こっています。JFrogは2024年にHugging Faceで約100個の悪意のあるモデルを発見しました。これらはロード時にリバースシェルを開きました。ReversingLabsは2025年に、ハブ自身のピクルススキャナーをすり抜けたさらに多くのモデルを発見しました。2026年5月にはHiddenLayerが、偽の星を獲得して18時間で244,000ダウンロードを達成し、インフォスティーラーを配布した偽の「OpenAIプライバシーフィルター」を捕捉しました。Hugging Face自身のProtect AIによるスキャンでは、51,700モデルにわたる352,000個の安全でない、または疑わしいファイルが検出されました。重み編集は現在ルーチンとなっており、破壊されたQwen3の1つは1ヶ月で200万ダウンロードを超えています。ベンチマークはバックドア付きファインチューンとクリーンなものを区別できません。これを悪化させているのは、攻撃者が最初から評判を築く必要さえなかったということです。次のブログでは、大手AI企業の従業員の漏洩したHugging Face認証情報をどのように発見したかを紹介します。これにより、攻撃者は信頼された名前空間の下でバックドアモデルをプッシュしたり、既存のモデルを静かに置き換えたりできるようになります。

防御者はどうすればよいか

ほとんどのチームは、ベースモデルに対して重みをdiffしたり、トリガーをリバースエンジニアリングしたりすることはありません。これは現実的です。今すぐ誰でもできることは、実行時にモデルが何にアクセスできるかを制御することです。これは、ネットワークアクセスとコマンド実行を分離し、両方をサンドボックス化し、どちらかの境界を越えるものをログに記録することを意味します。私たちはペイロードをraw.githubusercontent.comにステージングしました。これはほとんどの環境で既に信頼されているため、許可リストだけでは役に立ちませんでした。実行時の制御こそが、これを検出できたはずです。

トレーニングまたはファインチューニングを行うチームは、自分で構築していないモデルを、見知らぬ人からのプルリクエストと同じように扱ってください。誰が公開したか、トレーニングデータが文書化されているか、重みがベースモデルとクリーンにdiffするかを確認してください。

私たちはこのバックドアを週末で50ドル未満で構築しました。次のブログでは、大手AI企業の従業員の漏洩したHugging Face認証情報をどのように発見したかを紹介します。これにより、これが単一のポイズニングされたモデルから、信頼された名前空間全体にわたるサプライチェーン攻撃に変わる可能性があります。

ベンチマークがクリーンに見えるからといって、Hugging Faceから破壊されたモデルをプルして本番環境にドロップしないでください。

オープンモデルを実行している場合は、モデルサービングインフラストラクチャが実際に何に到達できるかを確認してください。どのようなシークレットを読み取れるか、どのような内部APIと通信するか、ツール呼び出しがサンドボックス化されているかを確認してください。クラウドインフラストラクチャとコードリポジトリをNeoに接続し、誰かが実行する前に、侵害されたモデルエンドポイントの爆発半径をマッピングさせましょう。