脆弱性「s1ngularity」とは何か？AI悪用・機密情報流出をもたらす新型サプライチェーン攻撃の概要

脆弱性「s1ngularity」とは何か？AI悪用・機密情報流出をもたらす新型サプライチェーン攻撃の概要

「s1ngularity」は、2025年8月に発覚した新型のサプライチェーン攻撃のコードネームです。人気のビルドツール「Nx」の公式パッケージが標的となり、攻撃者によって不正な改ざん版がnpmに公開されてしまいました。これら悪意あるパッケージはファイルシステム内をスキャンして認証情報（トークンや鍵）を収集し、それらを被害者のGitHubアカウント下に新規作成したリポジトリへ転送・公開するコードを含んでいました。
特にこの攻撃が注目されたのは、開発者向けAI支援ツールの悪用という新たな手口が含まれていた点です。攻撃者はシステム上にインストールされたLLMベースのAI CLIツール（Anthropic社のClaudeやGoogleのGemini、Amazonの「Q」など）をマルウェアの情報収集エージェントとして利用し、危険なフラグ付きプロンプトでファイルシステム内の秘密情報を探索させました。サプライチェーン攻撃においてAIを武器化した既知の事例は初めてであり、同種の手口に対する警戒が必要とされています。その結果、開発者のGitHub・クラウドサービス等の多数の認証情報が漏洩し、ソフトウェア開発コミュニティに大きな衝撃を与えました。

攻撃の被害範囲と影響：GitHubトークン大量流出から数千のプライベートリポジトリ公開まで拡大した深刻な事態

今回の攻撃による被害範囲は極めて広範で、漏洩した認証情報の数は数千件に上りました。GitGuardianの調査によると、この攻撃により少なくとも2,349件の異なる機密情報（シークレット）が1,079件のGitHubリポジトリ上に流出したことが確認されています。漏洩したシークレットの内訳を見ると、GitHub関連のアクセストークン（OAuthアプリキーや個人用PAT）が突出して多く、他にもクラウドサービスのAPI鍵やnpmトークンなど多岐にわたります。驚くべきことに、流出直後の分析ではこれらGitHubトークンの約90%が依然有効であったことが判明しました。これらのトークンはソースコードリポジトリやCIへのアクセス権を直接与えるため、実際に一部が悪用されて本来非公開であるプライベートリポジトリの内容が流出する結果につながりました。攻撃者は入手したトークンの一部を用いて、約190のユーザーや組織にわたる合計3,000件以上のリポジトリを強制的に公開状態に変更したと報告されています。つまり、本来社内限定やプライベートなコードがインターネット上に晒されるという二次被害が発生したのです。このようにGitHubトークン大量流出から数千のプライベートリポジトリ公開にまで被害が拡大した本事案は、開発者コミュニティにとって極めて深刻なセキュリティインシデントとなりました。

被害を受けたパッケージとバージョン：不正公開されたNx関連パッケージの種類と具体的な該当バージョン一覧

攻撃者によって不正なマルウェア入りバージョンが公開されたのは、Nx本体およびいくつかの公式プラグインライブラリです。具体的な侵害対象パッケージとバージョン番号は以下の通りです（これらのバージョンは既にnpmレジストリから削除済み）。Nxパッケージの侵害は2025年8月26日に発生しました:

• nx: 20.9.0, 20.10.0, 20.11.0, 20.12.0, 21.5.0, 21.6.0, 21.7.0, 21.8.0
• @nx/devkit: 20.9.0, 21.5.0
• @nx/enterprise-cloud: 3.2.0
• @nx/eslint: 21.5.0
• @nx/js: 20.9.0, 21.5.0
• @nx/key: 3.2.0
• @nx/node: 20.9.0, 21.5.0
• @nx/workspace: 20.9.0, 21.5.0

（以上の不正バージョン群は合計19種類に及び、正規の開発元から提供されたものに見せかけられていました。）

攻撃の流れ・サプライチェーン攻撃手法：PRインジェクションからマルウェア埋め込みとデータ窃取までの一連のプロセス

PRタイトルのコードインジェクション

攻撃者はまず、Nxプロジェクトに対して細工されたタイトルのプルリクエスト（PR）を送信しました。Nxリポジトリ内にはPRタイトル文字列をそのままShellコマンド内に埋め込んで実行してしまう脆弱なGitHub Actionsワークフローが存在しており、これがコードインジェクションに悪用されたのです。その結果、攻撃者のPRタイトルに仕込まれた悪意あるコマンドがCI上で実行され、リポジトリ内で任意のコード実行（RCE）が可能となってしまいました。

GitHub Actions権限濫用によるトークン窃取

上記ワークフローはpull_request_targetイベントで動作していたため、通常のpull_requestとは異なりリポジトリへの書き込み権限を持つGITHUB_TOKENが付与された状態で実行されました。攻撃者はこの高権限コンテキストを利用し、CI上でNxの公開用npmトークンが記載された設定ファイルに不正な改変を加えて、そのNPMトークンを自分の外部サーバー（webhookサイト）へ送信することに成功しました。これにより攻撃者はNxパッケージを自由に発行できるnpm資格情報（トークン）を完全に乗っ取ったことになります。

悪意のあるパッケージ公開（サプライチェーン侵害）

攻撃者は窃取したnpmトークンを用い、Nx本体および関連プラグイン計19件のトロイの木馬化バージョンを2025年8月26日夜にnpm上に公開しました。これらのパッケージは一見すると正規の開発元から提供された最新版のように見えますが、内部に前述のマルウェアのコードが仕込まれていました。多くのNx利用者は知らぬ間にこの改ざんバージョンをインストールしてしまった可能性があります。

インストール時にマルウェア実行（postinstall）

開発者の環境やCIで上記の不正パッケージがインストールされると、npmのpostinstallスクリプトとして仕掛けられたマルウェア（ファイル名：telemetry.js）が即座に実行されました。このスクリプトはLinuxおよびmacOS環境で動作し、システム内のファイルや環境変数を幅広く検索して各種認証情報（GitHubトークン、SSH秘密鍵、APIキー、暗号通貨ウォレット情報など）を可能な限り収集します。ユーザーの気付かないうちに、自身の端末内に保存された秘密データが根こそぎ抜き取られる状況になりました。

機密データの外部流出

マルウェアは集めた認証情報をBase64エンコードし、被害者のGitHubアカウント上に「s1ngularity-repository」という名前の新規公開リポジトリを自動作成して、その中にエンコード済みデータをアップロードしました。これらリポジトリは第三者にも閲覧可能であるため、被害者のトークンや鍵が誰もが見られる状態で漏洩することになります。実際にGitGuardianは、このように「s1ngularity-repository」という名前を含む不審なリポジトリが1,300件以上確認されたと報告しています。

持続性と妨害工作

加えてマルウェアは、被害端末のシェル設定ファイル（~/.bashrcや~/.zshrc）にsudo shutdown -h 0コマンドを追記する改変も行いました。これによりユーザーが新しくターミナルを開く度に即座にシステムのシャットダウンが試行され、パスワード入力を促されます。万一ユーザーが気付かず認証情報を入力してしまうと、マシンが即座にシャットダウンして作業継続が妨げられるという嫌がらせ的な副作用も発生しました。

AI CLIツールの悪用手口：開発者向けAIアシスタントを悪用した初の情報収集テクニックの事例と特徴

攻撃者はさらに、開発者向けのAI CLIツールを悪用するという巧妙な手口を見せました。マルウェアは被害システム上にAnthropic社のClaudeやGoogleのGemini、AmazonのQといったLLMベースのコードアシスタントCLIがインストールされている場合、それらを内部偵察の「エージェント」として利用しようとします。具体的には各AI CLIに対し、–dangerously-skip-permissionsや–yolo、–trust-all-toolsといった危険なフラグ付きのプロンプトを送り、ファイルシステム内の秘密情報を再帰的に探索させるコマンドを実行するのです。本来は開発支援のためのこれらAIツールがマルウェアの偵察役に転用された形であり、セキュリティ境界を迂回する新手法となりました。StepSecurityによれば、これは攻撃者が開発者向けAIアシスタントCLIをサプライチェーン攻撃のツールとして利用した初めての既知の事例であり、今後同種の手口に対する警戒が必要だとされています。こうしてAIツールを用いることで、マルウェアは従来型の監視をかいくぐりつつシステム内の機密データを抽出することが可能になっていました。

攻撃経路：GitHub Actionsのpull_request_target悪用とPRタイトルインジェクションによる侵入手法

今回の攻撃において侵入経路の鍵となったのは、GitHub Actionsのpull_request_targetトリガーの悪用とPRタイトルを介したコードインジェクションでした。Nxリポジトリでは2025年8月21日に、PRタイトルの形式を検証するためのGitHub Actionsワークフローが導入されましたが、このワークフローにPRタイトル文字列を直接Shellコマンドに渡してしまう欠陥が潜んでいました。攻撃者はこの脆弱性に目を付け、悪意のスクリプトをタイトルに仕込んだPRを送り付けることでCI上で任意コードを実行させたのです。
特にpull_request_targetという仕組みは、外部からのPRに対してもリポジトリ書込み権限を持つGITHUB_TOKENを付与してワークフローを実行するため、攻撃者のコードに本来守られているはずのシークレットへの書込み権限まで与えてしまいます。この結果、攻撃者はPR検証ワークフローの昇格した権限を悪用してNxの公開用npmトークンを読み出し、外部に送信することに成功しました。なお、この脆弱なワークフロー自体は問題発覚後すぐにリポジトリ管理者によって修正されましたが、攻撃者は修正前の古いブランチを標的にPRを投げることで隙を突いたと考えられています。（実際、当該バグはmasterブランチでは即座に修正されましたが、攻撃者はフォークしたリポジトリから古いブランチへのPRを送り付けて問題を引き起こしたと報告されています。）

postinstallスクリプトによる被害拡大：インストール時に自動実行される悪意あるコードの危険性と拡散経路

postinstallスクリプトの自動実行は、本攻撃の被害を一挙に拡大させたポイントです。npmパッケージはインストール時に任意のスクリプトを実行可能ですが、攻撃者はこれを悪用して利用者に気付かれずにマルウェアを起動させました。Nxは開発現場で広く使われており、プロジェクト依存関係に含まれていたり、VS CodeのNx拡張機能経由で自動的にインストールされたりするケースもあります。そのため、開発者が意識しないまま不正パッケージが実行され、機密情報が抜き取られる事態が各所で発生しました。また、このマルウェアはWindows環境では動作せず途中で終了するよう設計されており、主にLinux/macOSユーザーが被害を受けました。一度情報が漏洩すると、それを元にさらなる侵入やデータ公開（二次被害）が行われる可能性が高く、実際に前述のとおり漏洩したトークンを使って他のリポジトリが公開される事態も発生しています。さらに、postinstallスクリプトがシェル設定ファイルを書き換えて持続的な妨害を行う点も被害を深刻化させました。端末を開くたびに即シャットダウンが仕掛けられるため、マルウェア除去後も開発者の作業に支障をきたし、被害の復旧対応を複雑にしました。

漏洩した認証情報・被害例：流出したGitHub/NPMトークン1,000件超やクラウド鍵など多数の被害事例

本攻撃で漏洩した認証情報は非常に多岐にわたり、開発者や組織の重要な秘密が多数含まれていました。中でもGitHub関連のアクセストークン（OAuthアプリキーや個人用PATなど）が突出して多く、その数は1,000件以上に上ります。下図に示すように、GitHub OAuthトークンが漏洩シークレット種別の中で最も多く、次いで個人用アクセストークン（PAT）や各種クラウド・AIサービスのAPIキーが多数を占めていることが分かります。
「s1ngularity」攻撃で漏洩した有効な認証情報の上位10種類。GitHub OAuthトークンおよびPersonal Access Token (PAT) が突出して多いことが分かる。各種クラウドサービスやAIサービス用のAPIキー、データベース認証情報なども含まれている。
驚くべきことに、流出直後の調査ではこれらGitHubトークンの約90%が依然有効でした。これらのトークンはソースコードリポジトリやCI/CDへのアクセス権を直接与えるため、無効化が遅れるとさらなる不正アクセスにつながり得ます。実際に一部の有効なトークンは悪用され、非公開リポジトリの内容が流出する二次被害が発生しました（前述）。さらに、クラウドサービス（AWSやGCPなど）のAPI鍵やOpenAI・Google等のAIサービス用キー、データベースの資格情報、npm公開用トークン、SSH秘密鍵、さらには暗号通貨ウォレットのキーストアに至るまで、多種多様な機密情報が開発環境から漏洩していたことが確認されています。

今すぐできる対策と推奨対応：被害を最小限に食い止めるトークン無効化・パッケージ削除など緊急措置と推奨セキュリティ対応策

漏洩した認証情報の無効化

自身のGitHub個人アクセストークン(PAT)やOAuthアプリキー、npmの認証トークン、クラウドAPI鍵など、流出した可能性のあるあらゆるシークレットを速やかにローテーション（無効化・再発行）してください。特にGitGuardianも指摘しているように、対応の遅れはさらなる被害拡大につながる恐れがあり、迅速な無効化措置が肝要です。

不正パッケージの排除

開発環境やCIで問題の悪意あるNxパッケージがインストールされていないか確認し、該当バージョンが含まれていた場合は直ちに削除・安全なバージョンへの置き換えを行ってください。公式から提供される新しい安全なバージョンへアップデートするとともに、依存関係のキャッシュに古い版が残っていないかもチェックしましょう。

マルウェア残存の確認と除去

システム上でマルウェアによる改変が残っていないか検査します。例えばホームディレクトリのシェル設定ファイル（~/.bashrcや~/.zshrc）に見覚えのないsudo shutdown -h 0の記述が追記されていれば削除してください。また、自分のGitHubアカウントに「s1ngularity-repository」という不審なリポジトリが作成されていないか確認し、もし存在する場合は削除するとともに、その公開リポジトリ経由で漏洩した情報が攻撃者に悪用され得る点に備えて対処してください（※これらの不審リポジトリについてはGitHubにより順次アーカイブ対応が取られています）。

アカウント保護の強化

被害を受けた可能性があるサービスのパスワード変更や多要素認証（2FA）の有効化を行い、攻撃者によるさらなる不正アクセスを防ぎます。特にGitHubやnpmのアカウントは2FAを必ず有効にし、漏洩したトークンだけではアクセスできない状態にしてください。また、npmパッケージのメンテナーであれば、GitHub Actions経由でパッケージを公開する際にGitHubのTrusted Publisher機能を利用して署名付きで公開し、長期利用のトークンを使わないようにする改善も検討すべきです。さらに、CI/CDでのデプロイ時にはOIDCによる一時的なクレデンシャルや署名付きワークフローの採用など、トークン漏洩リスクを低減する工夫も必要です。

関係者への連絡

漏洩した資格情報に紐づくリソースが組織のものである場合、速やかに組織内のセキュリティ担当者に報告し、組織全体での一斉トークン無効化やパスワード変更など協調対応を実施してください。また、漏洩により影響を受け得る取引先やユーザーがいる場合も、早急に通知して被害拡大防止に努めましょう。

今後のセキュリティ強化ポイントと教訓：サプライチェーン防衛やCI設定見直しなど再発防止に向けた重要対策と心得

CI/CDワークフローの安全性見直し

継続的インテグレーション（CI）環境の構成を再点検し、今回のようなPR由来のコード注入を防ぐ対策を講じることが重要です。GitHub Actionsを使用する場合、ワークフロー内で外部入力（PRタイトルや本文など）を直接シェルコマンドとして実行しないよう徹底し、pull_request_targetトリガーの使用は必要最小限に留めるか実行権限を厳格に制限してください。GitHubが公開しているガイドや過去の類似事例を参考に、ワークフローの脆弱性を事前に発見・修正する運用（例：コードスキャンやテスト導入）も求められます。

公開プロセスの強化とシークレット管理

ソフトウェアのリリースプロセスにおける認証情報の扱いを見直し、秘密管理を強化する必要があります。今回Nxチームはインシデント後にnpm公開用トークンを破棄して2FA必須化し、全パッケージの公開方法をTrusted Publisher（署名付きCI公開）に移行するなどの是正措置を講じました。同様に、パッケージ公開やCIでのデプロイ時には長期固定のトークン類を使わず、OIDCを用いた一時的な資格情報や署名付きワークフローを採用することでトークン漏洩リスクを低減できます。また、全ての主要アカウントに二段階認証（2FA）を導入し、不正入手されたトークンだけでは侵入されないようにしておくことも基本です。

サプライチェーン防御策の導入

開発ライフサイクル全般でサプライチェーンセキュリティを強化することも重要です。外部ライブラリの信頼性検証（署名付きリリースの検証など）やソフトウェア部品表（SBOM）の管理、依存関係の更新モニタリングといった多層的防御策を導入・徹底すべきでしょう。今回のようにビルドパイプライン自体が侵害されたケースでは、パッケージのProvenance（改ざん検知用の署名付き証跡）だけでは防ぎきれませんでした。しかし多層的な対策を講じておけば、不正な変更の早期検知やパッケージ改ざんの迅速な発見につなげることが可能です。例えば開発元はCodeQL等の静的解析でワークフローの脆弱箇所をチェックしたり、公開前のパッケージにマルウェアスキャンを適用したりするといった対策も検討すべきです。

異常検知とインシデント対応能力

万一マルウェアが混入しても被害を最小限に食い止められるよう、異常な挙動の検知システムを整備しておくことが重要です。例えばStepSecurityのHarden-Runnerのようなツールを導入すれば、npmインストール時の外部への不審なAPI呼び出しや不正なプロセス生成をリアルタイムで監視・検出し、CIパイプライン上でマルウェアの活動を素早くフラグできます。また、GitGuardianのようなシークレット漏洩検出サービスを活用し、自社や組織のトークンが公開リポジトリに露出した際に即座に把握・無効化できる体制を整えておくことも有効です。実際、GitGuardianは「漏洩の迅速な検知、影響の精査、数千に及ぶ非人間IDのトークンを協調的に無効化する能力は、サプライチェーン攻撃が発覚から数時間で漏洩した認証情報を武器化できる時代におけるレジリエントなソフトウェアデリバリーの新たな基準になりつつある」と指摘しています。

AIツール利用のガイドライン策定

開発現場で利用が広がるAIコーディング支援ツールについても、セキュリティ上のガイドラインを設ける必要があります。今回の事件ではローカルのAIエージェントが攻撃に悪用され得ることが示されたため、社内規則としてAIツールに過剰なファイルシステムアクセス権を与えない、–yoloや–trust-all-toolsといった危険なオプションを不用意に使用しない等のルールを定めることが考えられます。実際、セキュリティ企業Snyk社も「ローカルのAIコーディングエージェントは他の特権的な自動化ツールと同様に扱い、ファイルやネットワークへのアクセスを制限し、YOLOモードで安易に実行しないこと」と強く勧告しています。

開発者・組織のセキュリティ意識向上

最後に、本件から得られる教訓として「自分は関係ない」と思わないことが挙げられます。Nxを直接使っていない開発者であっても、同僚やプロジェクトがNxを利用していれば影響を受ける可能性があり、実際「自分のプロジェクトはNxを使っていないから関係ないとは言えない攻撃」であると指摘されています。日頃からサプライチェーン攻撃のリスクを念頭に置き、自身の開発環境やCI設定に潜む脆弱箇所を洗い出す習慣が重要です。また、万一インシデントが発生した際には速やかに情報共有し、チーム全体で秘密情報のローテーションや影響範囲の調査を実施する初動対応力が被害拡大を防ぐ鍵となります。今回の一件は、ソフトウェア開発組織に対してセキュリティ対応力の強化と、AI時代における新たなリスクへの備えを促す貴重な教訓となりました。