3つの攻撃、3つの呼び名、しかし欠陥は1つだけです。AIコーディングエージェントは、幻覚によって生成された識別子を検証済みのコマンドとして扱ってしまいます。
執筆: Shane Warden氏（ActiveState プリンシパルアーキテクト）
AIコーディングエージェントにツールの取得を指示すると、時折それらしい名前が返ってくることがありますが、実際には存在しないケースがあります。これまで開発者はこうしたミスを、コンパイラやテストが止めてくれるはずだと考えて無視してきました。しかし残念ながら、この前提は危険であり、誤りです。
私たちは事実上、時として単語を推測してしまう言語モデルにroot権限を与えているのであり、攻撃者はそれを悪用する方法を心得ています。
攻撃の手口はこうです。攻撃者はLLMが生成し、後にどうにかしてアクセスされるであろうURL、ソフトウェアライブラリ名などを計算で予測できます。攻撃者はその名前を押さえたうえで罠を仕掛け、待ち構えるのです。パスワードを盗む必要はありません。フィッシングメールを送る必要もありません。
人間にリンクをクリックさせる必要すらありません。必要なのは、どこかの誰かが、自動化されたプロセスに悪意あるものを取得する権限を与えることだけです。
テルアビブ大学、テクニオン、Intuitの研究者らは2026年7月8日に論文を発表しました。Ben Nassi氏の研究グループに所属するAya Spira氏率いるチームは、こうした架空の名前が予測可能であることを実証しました。
研究チームはCursor、Windsurf、GitHub Copilot、Cline、Gemini CLI、OpenClawにまたがり、複数のプロンプトでテストを実施しました。その結果、リポジトリのリクエストではモデルが最大85%の確率で同一の名前を幻覚として生成し、スキルのインストールに関しては100%の確率で同一の名前を幻覚として生成しました。
「スロップスクワッティングは偽のパッケージ名を悪用するものでした。ファントムスクワッティングは偽のドメインを悪用するものでした。そしてハルスクワッティングは、偽のリポジトリやスキルを悪用します」とWarden氏は述べています。「いずれのケースでも、エージェントは誰も検証していない名前を信頼してしまっているのです」
今回の見返りはボットネット
この比較だけでは、今回の新しさを十分に伝えきれていません。スロップスクワッティングとファントムスクワッティングは、一度に1台のマシンに攻撃者のコードを送り込むものでした。一方でハルスクワッティングは攻撃者にとってさらにスケールします。かつてボットネットの運用者が実際のマシン侵害を必要としていた配信作業を、エージェント自身がやってくれるからです。
パスワードの盗難もなければ、デバイスからデバイスへと這い回るワームもなく、狙うべき単一のOSも存在しません。露出したエージェントを稼働させているマシンであれば、どれでも標的になり得ます。
研究者らはこの攻撃が大規模に再現可能であることを実証するために、まさにこの攻撃を構築しました。それゆえ彼らは自分たちの示した数値を上限ではなく下限として扱っています。「攻撃は常に進化する」と彼らは記しています。「決して衰えることはない」
3度目は偶然ではなくパターン
セキュリティチームは過去6カ月間で、この種の欠陥を3度目撃しています。
2026年1月（スロップスクワッティング）: Aikido SecurityのCharlie Eriksen氏は、AIエージェントがreact-codeshiftという偽のnpmパッケージを237件のプロジェクトにわたってインストールしようとしていたのを発見しました。同氏は攻撃者にその名前を先取りされないよう、自ら登録しました。
2026年6月（ファントムスクワッティング）: Palo Alto NetworksのUnit 42は、言語モデルが幻覚として生成する25万件のドメインを発見しました。それらのドメインは誰でも登録可能な状態でした。
2026年7月（ハルスクワッティング）: Spira氏の研究チームは、攻撃者が予測可能な名前を事前に取得することでAIエージェントを乗っ取れることを示しました。
いずれの攻撃も、根底にある同じ欠陥に依存しています。システムは、誰かが検証・確認したかどうかに関わらず、モデルが生成した名前をそのまま信頼してしまうのです。
設計原則の失敗：レイトバインディング
この問題は、互いに関連する2つの要因に起因しています。
第一に、言語モデルは確率に基づいて出力を生成します。適切な入力を与えれば、予測可能な出力を生成します（もちろん決定論的ではありませんが、論文が示す通り、攻撃ベクトルを生み出すには十分な予測可能性があります）。これはレインボーテーブルを彷彿とさせます。パスワードハッシュの出力をあらかじめ生成しておく手法です。
ある入力が特定の（脆弱な）ハッシュを生成することを知っていれば、そのハッシュさえ入手できれば、誰かのパスワード自体を知る必要はありません。
第二に、開発者はこうした言語モデルが生成した出力に基づいてコマンドを実行するコードやパイプラインを構築し、実行しています。よほど注意深くない限り、エージェントはコードやデータの出所を精査・検証する機会を得る前に、それらを実行あるいは取得してしまいます。
ソフトウェアアーキテクチャにおいて、この種のレイトバインディングは柔軟性をもたらします。しかしセキュリティアーキテクチャにおいては、未検証の外部データソースを信頼することが重大な脆弱性を生み出します。危険は、テキスト生成とコード実行の間に生じる隙間に潜んでいます。昨日（あるいは1時間前）に確認した時点では安全で正しかったものが、その後変化している可能性があるのです。
開発者は製品をより速く出荷しようと急いでいます。彼らはビルドインフラを使い捨てのツールのように扱いながら、それでいてダウンロード、変更、デプロイに関する広範な権限をこうしたツールに与えています。その結果、タイポスクワッティングや依存関係の混同を自動化してしまっているのです。
エージェントが十分な人間によるレビューを経ずにコードを取得・実行する権限を持つようになった今、攻撃のリスクは高まる一方です。
リスクは依存関係ツリーの奥深くまで及ぶ
リスクはトップレベルのパッケージにとどまりません。エージェントが実在する名前を持つ実在のパッケージを選ぶこともあり得ます。最新のセキュリティツールはそのトップレベルのパッケージをチェックするかもしれません。しかし、ツリーの3層、4層下にある推移的依存関係まで検査することはめったにない、ということをご存じでしょうか。
開発者は、トップレベルのソースコードを読んで「問題なさそうだ」とEnterキーを押すだけでは、こうした依存関係を精査することはできません。さらに厄介なのは、以前のバージョンでは問題がなかった依存関係が侵害された場合、昨日まで有効だったルールが今日はもう自分を守ってくれないかもしれないという点です。
攻撃者が奥深くの依存関係、あるいはそれが依存する何かを侵害できれば、自動化パイプラインがその侵害をそのままシステム内に持ち込んでしまう恐れがあります。
従来のセキュリティ対策は通用しない
研究者らは、今回の調査結果があくまで最低限のリスク水準を示すものであると指摘しています。こうした攻撃は今後、標的の絞り込みにおいてさらに速く、より正確になっていくでしょう。既存のセキュリティツールは、こうした攻撃パターンに対して太刀打ちできません。
2026年6月、Trail of Bitsは1時間足らずでエージェントのスキルストアスキャナーを突破しました。スキャナーは隠されたペイロードではなく、表向きに申告された内容を検査しているにすぎないためです。
SSL証明書やDNSSECもこの脅威を止められません。偽のドメインを登録した攻撃者は、無料のLet’s Encrypt証明書を容易に取得できます。証明書はそのドメインの所有者が誰であるかを証明するものであり、ユーザーがそこに接続しようと意図していたことや、そのドメインが安全であることを証明するものではありません。
DNSSECは他者によるドメインの乗っ取りを防ぎますが、そのドメインが、最新モデルがユーザーをそこへ誘導すると攻撃者が予測した結果、昨日登録されたばかりのものだったとしたらどうでしょうか。
取り込みパイプラインの修正
システムを守るためには、パイプラインが未精査のコードやデータを一切実行しないようにする必要があります。その精査と検証は、AIの速度に合わせて自動的に行われなければなりません。人間によるレビューでは、自動化されたAIツールのスピードに追いつけないのです。
エンジニアリングチームはこの問題に正面から取り組む必要があります。社内で検証パイプラインを構築するために多大な時間を費やすか、既存のガバナンスソリューションを導入するかのいずれかです。
個々のツールにパッチを当てるだけのチームは、この攻撃手法の新たな亜種を何年も追いかけ続けることになるでしょう。根底にある設計上の欠陥を修正するチームは、モデルが信頼できないコマンドを実行する前の段階で攻撃を食い止めることができます。
組織は、ActiveStateのCurated Catalogのような、精査済みコンポーネントで構成されたプライベートかつポリシーで管理されたリポジトリを通じて、オープンソースの依存関係を解決すべきです。このカタログは、エージェントがダウンロードする前にパッケージを検証します。この精査に通らないパッケージはエージェントから完全に見えない状態になるため、悪意あるコードがシステムに入り込む前に処理が失敗します。
これはスキャンとは異なる防御手法です。Trail of Bitsがスキャナーを突破できたのは、スキャナーが未知のアップロードを取得のまさにその瞬間に検査するためであり、その瞬間こそ攻撃者がペイロードを検出回避するよう最適化してある時点だからです。
Curated Catalogはその瞬間そのものを完全になくしてしまいます。どのエージェントかが要求する以前に精査・検証済みのコンポーネントしか提供しないため、突破すべき未知のアップロードがそもそも存在しないのです。この一手により、統計的な当て推量が、信頼できるリソースか、あるいは人間による調査を要する明確な失敗のいずれかへと変わります。
あなたのチームが現在行っている取得のうち、どれだけが未チェックのまま通過してしまうか確認したい場合は、ActiveStateにOSSリスクアセスメントを依頼し、攻撃者に先んじて把握しておきましょう。
よくある質問
ハルスクワッティングとは何ですか？
ハルスクワッティングとは、AIコーディングエージェントが予測可能な形で創作してしまう架空のリポジトリ名、パッケージ名、スキル名を研究者や攻撃者が事前に計算し、それらの名前を先に登録したうえで悪意ある命令を仕込んでおき、実際のユーザーのエージェントがそれを探しに来るのを待ち構える攻撃です。
スロップスクワッティングやファントムスクワッティングとは何が違うのですか？
3つとも、エージェントが誰も検証していない名前を信頼してしまうという同じ欠陥を悪用していますが、標的とするリソースは異なります。スロップスクワッティングはnpmパッケージ名を、ファントムスクワッティングはWebドメインを標的とし、ハルスクワッティングはリポジトリとエージェントのスキルを標的としたうえで、エージェント自身が持つツール使用権限を通じて直接ペイロードを実行します。
既存のセキュリティスキャナーでこれを検知できますか？
確実には検知できません。Trail of Bitsはテストしたすべての公開スキルストアスキャナーを1時間足らずで突破しました。スキャナーが検査しているのは、隠されたペイロードではなく、未知のアップロードが表向きに申告している内容にすぎないためです。事後的な静的スキャンは、そのスキャンを打ち破るために特化してペイロードを構築した攻撃者との競争に挑んでいるようなものです。
エンジニアリングチームは今週何をすべきですか？
取得前の検証機能が存在する場所ではすべて有効にしてください。多くのエージェントフレームワークはこの機能をデフォルトで無効にしたまま出荷されています。オープンソースの依存関係解決については、エージェントに公開レジストリから直接取得させるのではなく、ガバナンスの効いた事前精査済みのカタログ経由で行うようにしてください。
この問題はすべてのAIコーディングエージェントに等しく影響しますか？
研究者らは、Cursor、Windsurf、GitHub Copilot、Cline、Gemini CLI、OpenClawなど、異なる基盤モデル上に構築されたツール間で、幻覚として生成される名前が一貫していることを発見しました。これは特定のベンダーに限定された欠陥ではなく、エージェントの構築方法と権限付与のあり方に根差したパターンなのです。
