タイプスクワッティング（人気パッケージのタイプミス版を登録し、開発者が誤って入力してインストールするのを待つ行為）は、npmにおいて10年前から存在する手法だ。これは決して新しいものではない——レジストリにはこれに対する保護策が備わっている。
そしてAIが登場し、再び全てを変えた。スロップスクワッティングは、タイポスクワッティングの新たなAI版だ。攻撃者は人間のタイプミスではなく、AIの幻覚——LLMが自信満々に推奨する実在しないパッケージ名——に賭ける。しばらくは理論上のリスクと見なされていたが、もはやそうではない。AIの幻覚が我々の目の前に現れ、スロップスクワッターもまたここに存在する。
本稿では、スロープスクワッティングの仕組み、研究者が現在実環境で発見している内容、そして実際にどのような対策が可能かについて考察します。
スロープスクワッティングとは何か？
スロープスクワッティング（幻覚スクワッティングとも呼ばれる）とは、攻撃者がAIモデルが幻覚を起こしやすいパッケージ名を登録し、開発者がAIの推奨に基づいてそれをインストールするのを待つ攻撃手法である。スクワッティング攻撃者は、AIアシスタントが存在しないパッケージ名を自信を持って提案すること、そして開発者がそれを自分が要求した実在のパッケージだと信頼することに依存している。
開発者がこのパッケージ名でインストールを実行すると、攻撃者のパッケージがインストールされます。このパッケージは通常、インストール後のスクリプトを実行し、環境内に存在するあらゆる認証情報（API 、クラウドトークン、npm認証トークンなど）を窃取し、攻撃者に転送します。
一部のパッケージはインストール後スクリプトに攻撃コードを組み込むだけだが、より洗練されたパッケージはパッケージ自体に悪意のあるコードを一切含まず、代わりにnpmのURLベースの依存関係 を利用して依存関係 インストール時に外部サーバーからペイロード依存関係 明らかに悪意のあるコードが存在しないため、単純な静的スキャナーにはパッケージはクリーンに見える。
たとえば、AIにJavaScriptリンターパッケージのインストールを依頼するとします。AIは 未使用インポート インストールするかどうか尋ねてきます（もし尋ねなければ、完全にスキップされます）。これは以前使ったパッケージのように聞こえるので、インストールします。
Claudeは実行したい: npm install unused-imports
[y] 承諾 [n] 拒否 [e] 編集 [Esc] キャンセルしかし、真のパッケージは eslint-plugin-未使用インポート実は、 未使用インポート 悪意のあるパッケージであり、なんと！あなたはマルウェアをインストールしてしまったのです！（これは実際には リアル ちなみに、悪意のあるパッケージであり、意図的なスロップスクワッティング攻撃の可能性もある。 それを調べることができます Aikido インテル. npmは現在セキュリティ上の保留状態にあります)。
LLMは実際にパッケージ名をかなり頻繁に幻覚します。 Aikido Securityのデベロッパーアドボケートであるマッケンジー・ジャクソンは、Secure Disclosureポッドキャストのエピソードで遭遇した幻覚について説明した。彼はAIに、Node.jsプロジェクトをOrientDBデータベースに接続する手助けを求めた。これは技術的には可能だが珍しい組み合わせであり、明らかなパッケージソリューションは存在しない。 モデルは困惑を認める代わりに、パッケージ名をでっち上げた。マッケンジーはAIの思考プロセスについてこう語る。「あなたに提供できるものは何もないが、何かを提供しなければならない。だから、このためのパッケージはこう呼ばれるだろう」
スロープスクワッティングはタイポスクワッティングとどう違うのか？
タイポスクワッティングとは、攻撃者が人気パッケージと十分に似た名前で悪意のあるパッケージを登録し、ユーザーがタイプミスで誤ってインストールしてしまう手口である。 攻撃者は、見落としやすいスペルミスが発生しやすい高ダウンロード数のパッケージを見つけ、ハイフンを削除したり、2文字を入れ替えたり、余分な文字を追加したりして、誰よりも早くそのスペルミス版パッケージを「占拠」します。タイポスクワッティングは少なくとも2017年以降、npmにおける常態化現象となっています。当時、攻撃者が公開した... クロス環境人気のスクワット クロス環境 パッケージ。npmは現在、既存のパッケージ名と類似しすぎるパッケージ名の登録を防止することで、この問題に対する保護機能を備えています。
スロップスクワッティングはタイポスクワッティングの一種だが、人間の誤入力に賭ける代わりに、攻撃者はAIが自信を持って誤った判断を下すことに賭ける（そう、今のAIの信頼性がそこにある）。従来のタイポスクワッティングとの主な違いは、変種が全く異なる見た目である点と、前者では攻撃者が選択できるドメイン名の数がより多い点だ。
例えば、AIが生成したPythonパッケージ名の8.7%が有効なJavaScriptパッケージであることが判明した。この場合、モデルは実在のものへの正しい関連付けを行っているが、単に間違ったエコシステムで発生している。攻撃者が他エコシステムのパッケージ名を登録する絶好の機会となる。
USENIX Security 2025の研究者らはテストした 576,000のコードサンプルにわたる16のモデルを分析した結果、幻覚は予測可能なパターンに従うことが判明した：38%は以下のような混同である エクスプレス・マングースモデルが2つの実在するものを組み合わせたものは13%、タイプミス変種は51%、純粋な捏造は51%を占める。これはタイポスクワッティングが提供した範囲をはるかに超えるスクワット可能な名称プールであり、タイポスクワッティングとは異なり、これらの新規名称はnpmの保護システムにおいて「類似する対象」が存在しない。
スロープスクワッティングは今起きているのか？
我々もそう考えている。スロープスクワッティングの手口と一致する名前のマルウェアパッケージを確認しているが、攻撃者がその名前で何を意図しているかは証明できない。 未使用インポート先程お話しした、確認済みの悪意あるパッケージです。2月上旬時点でも、週に233回のダウンロードが継続していました。これらの開発者は、依然としてこのパッケージを指し示すAIの推奨に従っているか、依存関係ツリー内のどこかに存在して再インストールしているか、あるいは更新されていないドキュメントやStack Overflowでこのパッケージを見つけたかのいずれかです。
しかし、研究者たちは確実に現実世界におけるスロップスクワッティングの最初の前兆を発見し、実証しつつある。2024年初頭、 ラッソ・セキュリティのバー・ラニャドは、AIモデルがPythonパッケージを繰り返し幻覚表示していることに気づいた 呼ばれた huggingface-cli 実際のツールは異なる方法でインストールされます。 pip install -U "huggingface_hub[cli]", しかしモデルは、より短い、存在しないバージョンを提案し続けた。Lanyadoはその名前で空のパッケージをPyPIにアップロードし、何が起こるか試した。
huggingface-cli 3か月で3万回以上の正規ダウンロードを記録した。アリババは幻覚的なインストールコマンドを、自社の公開リポジトリの一つにあるREADMEファイルにコピペしていた。パッケージ自体は無害だったが、Lanyadoはこの戦略が有効であることを実証した。攻撃者に先んじてLanyadoがこれを発見したのは、アリババにとって幸運だったと言える。
自ら拡散したAIパッケージの幻覚
チャーリー・エリクセン、セキュリティ研究者 Aikido さらに驚くべきものを見つけた– 現実のAIインフラに拡散する幻覚的なパッケージ名。誰も意図的に仕掛けたわけではないのに、現実のエージェントが実行を試みる。2026年1月、チャーリーはこのnpmパッケージを名乗った react-codeshift. そのパッケージは本物ではなく、作者もおらず、間違いなく以前に登録されたこともなかった。名前は クラシック 混同による幻覚。類似した名前を持つ二つの実在パッケージが存在し、 jscodeshift そしてreact-codemodLLMが組み合わせて作り出した名称 react-codeshift.
このパッケージは、47個のLLM生成エージェントスキルを含む単一のコミットで初登場した。AIにコーディングエージェントの指示セットを生成させようとした際、そのタスク実行に必要なパッケージ名をAIが妄想したものと推測される。人間のレビュー（少なくともテスト）は行われなかったため、このAIの妄想はGitHubを通じて不滅のものとなった。
チャーリーがそれを見つけた頃には、 未受領小包に関する彼の研究この存在しないパッケージ名は、フォークを通じて237のリポジトリに拡散し、日本語に翻訳されていた。チャーリーがこれを主張した後、 react-codeshift 毎日数回のダウンロードが継続的に発生していた。これらはAIエージェントがスキル指示に従い、実環境でnpxインストールをトリガーしているものである。攻撃者が先に登録していた場合、有機的に拡散する大規模なスロープスクワッティング攻撃が発生していた可能性がある。
スロップスクワッティング攻撃から身を守る方法
発行元を確認してください。名前だけでなく
明らかな解決策はインストール前にパッケージ名を確認することだが、実際にはそれほど単純ではない。ダウンロード数は信頼できる指標ではない（悪意のあるパッケージでも日常的にダウンロードされている事例を確認済み）。真に重要なのは発行元である：誰がこのパッケージを登録したか、いつ登録したか、そしてそれが正当なメンテナから期待される情報と一致するか？ あるパッケージが ESLint メンテナンス情報がなく、登録日が先週の火曜日であるプラグインは、ダウンロード数に関わらず危険信号です。
自律的なパッケージインストールを特権操作として扱う
確認なしでパッケージをインストールできるAIエージェント、バイパスモードのClaude Code、エージェント型コーディング環境、または広範なnpm権限を持つCIパイプラインを運用している場合、通常人間が行う検証ステップが省略されます。権限があればエージェントはそのまま実行を続行します。これがスロープスクワッティングの脅威モデルの中核であり、権限範囲を適切に設定する必要があります。
依存関係ツリー全体をスキャンする
一部の幻覚的なパッケージ名は、直接インストール依存関係 ネストされた依存関係 として扱われるため、package.jsonに表示されません。ソフトウェア構成分析（SCA）スキャナーは依存関係ツリー全体を調査し、隠れた悪意のあるパッケージを検出します。
npmレベルでの保護にはSafeChainをご利用ください
Aikido セーフチェーン は、オープンソースのラッパーです。 npm, npx, 毛糸、および pnpm パッケージインストールコマンドをインターセプトし、それらを Aikido インテル 何かがあなたのマシンに到達する前に。
まとめ
未請求のパッケージ名は常に請求可能でしたが、現在ではAIが偽のパッケージ名を自信を持って提示しインストールさせ、さらにAIエージェントがそれらの名前をリポジトリ全体に拡散させるようになっています。
バイブコーディングが標準化し、ロブスターをテーマにしたAIエージェントが人間の監視なしにコーディングを始めるケースが増えるにつれ（『OpenClawのセキュリティ対策が馬鹿げている理由』を参照）、実行前に人間が不適切なパッケージ名を発見できる機会は縮小し続けている。LLMが生成する名前には一貫性と再現性があることが確認されており、攻撃者もこの手法を習得しつつある。
依存関係ツリーを確認してください。発行元を検証してください。そして、パッケージマネージャーとレジストリの間に位置し、代わりに検証を行うツールを使用してください。
