7月24日、Shane Wardenが「Slopsquatting, Phantom Domains, and HalluSquatting Are the Same AI Attack」と題した記事を公開した。AIコーディングエージェントがハルシネーションで生成した架空の名前を攻撃者が悪用する「HalluSquatting」を含む一連の攻撃パターンは、名称こそ異なるが根本的な欠陥はすべて同一だ。記事はその共通構造と実態を詳しく整理している。
「3つの攻撃」は実は同一の欠陥
過去半年で、AIコーディングエージェントのハルシネーションを悪用した攻撃が3回観測されている。名前は違うが、根本的な欠陥は同一だ。
- 2026年1月（Slopsquatting）：Aikido SecurityのCharlie Eriksenが、AIエージェントが237件のプロジェクトで
react-codeshiftという架空のnpmパッケージをインストールしようとしていることを発見した。 - 2026年6月（Phantom Squatting）：Palo Alto NetworksのUnit 42が、LLMがハルシネーションで生成するドメイン名が25万件存在し、誰でも登録できる状態にあることを報告した。
- 2026年7月（HalluSquatting）：テルアビブ大学・テクニオン・Intuitの共同研究チームが、AIエージェントが架空のリポジトリ名やスキル名を予測可能な確率で生成することを実証した。
共通点を一言で言えば「エージェントが、誰も検証していない名前を信頼して実行する」という点だ。
HalluSquattingの核心：ハルシネーションは予測可能
2026年7月8日に公開された研究論文が今回の記事の軸になっている。Aya Spira率いるチームは、Cursor、Windsurf、GitHub Copilot、Cline、Gemini CLI、OpenClaw（いずれもAIコーディングエージェント）の複数エージェントに対して同一のプロンプトを与え、生成される架空の名前がどれだけ一致するかを検証した。
結果は衝撃的だ。
- リポジトリへのリクエストで、複数モデルが最大85%の確率で同一の架空名を生成した
- スキルのインストールでは**100%**の一致率を記録した
攻撃者はこの予測可能性を利用して、エージェントが生成しそうな名前をあらかじめ登録し、悪意あるペイロードを仕込んで待つ。パスワード窃取もフィッシングも不要で、「自動化されたプロセスが何かを取得する許可」さえあれば攻撃が成立する。
論文中で研究チームが「攻撃は常に改善される。悪化することはない」と記していることも重要で、現時点の数字は下限値に過ぎない。
設計上の問題：「レイトバインディング」
著者はこの問題をレイトバインディング（late binding）という設計上の欠陥として整理している。
LLMは確率に基づいてテキストを生成する。入力が同じなら出力も高確率で同じになる。これはかつてのパスワードクラッキングにおけるレインボーテーブル（パスワードのハッシュ値を事前に大量計算して蓄積した逆引き表。手元のテーブルと照合するだけで元のパスワードを特定できる）に似た構造だ——ハッシュの入力を事前計算しておけば、パスワードを知らなくても突破できる。HalluSquattingも同様に、「モデルが高確率で生成する名前」を事前にリストアップし、先回り登録しておくだけで攻撃が完成する。
問題は、この生成されたテキストをエージェントが「検証なしに」実行することにある。テキスト生成とコード実行の間に検証が入らないため、「昨日は安全だったものが今日は危険になっている」状態が生まれる。
さらにリスクは依存関係ツリーの深部にも及ぶ。トップレベルのパッケージが本物であっても、3〜4層下のトランジティブ依存に悪意あるコードが混入していれば、既存の多くのツールはそれを検出できない。
既存のセキュリティツールでは防げない
記事はこの点を明確に述べている。
- Trail of Bitsは、公開されているすべてのスキルストアスキャナーを1時間以内に突破した。同チームの検証によれば、スキャナーはアップロード時の「申告内容」を検査するが、隠れたペイロードは見落とす構造になっているという。
- SSL証明書とDNSSECも無効だ。Let's Encryptで無料証明書を取得すれば「ドメインの所有者」は証明できるが、「ユーザーがそこに接続する意図があったか」「ドメインが安全か」は証明できない。
対策の方向性
記事が示す対策の核心は「フェッチ前の検証」だ。スキャナーが「取得後に検査する」のに対し、検証済みコンポーネントのみを提供するキュレートされたカタログを挟むことで、「未検証のアップロードが発生するタイミング自体をなくす」アプローチが有効とされている。
実装面での即効策として挙げられているのは以下の2点だ。
- プリフェッチ検証をオンにする（多くのエージェントフレームワークはデフォルトでオフになっている）
- オープンソース依存関係の解決を、パブリックレジストリへの直接フェッチではなく、ガバナンスされた事前検証済みカタログ経由にする
なお、具体的なツールや実装ガイドラインについては元記事が参照先を示しているため、実際の導入にあたってはそちらを確認することを勧める。
個々のツールにパッチを当てる対応では、この攻撃の新しいバリエーションを追い続けることになる。根本的な設計の欠陥——未検証の名前をエージェントが信頼するという構造——を修正しない限り、問題は形を変えて繰り返す。
詳細はSlopsquatting, Phantom Domains, and HalluSquatting Are the Same AI Attackを参照していただきたい。
