2026年10月以降に相次いだセキュリティ事案が示しているのは、開発チームの認証情報は、自社の手元ではなく、預けているプラットフォームや依存しているソフトウェアから漏れることが多いという事実です。ベンダーへの侵入は防げなくても、漏えいしたときの被害の大きさは事前に決めておけます。
はじめに
2026年10月以降に相次いだセキュリティ事案が示しているのは、開発チームの認証情報は、自社の手元ではなく、預けているプラットフォームや依存しているソフトウェアから漏れることが多いという事実です。ベンダーへの侵入は防げなくても、漏えいしたときの被害の大きさは事前に決めておけます。
11月3日、ブロックチェーンノードサービスの Chainstack が顧客にセキュリティ通知を送りました。攻撃者はサードパーティ製コンポーネントを経由してインフラに侵入し、顧客の組織名、アカウント所有者名、メンバーのメールアドレス、パスワードハッシュを取得した可能性があります。ノード認証情報を保管するシステムにもアクセスされていました。Chainstack はすべての顧客に、パスワードの変更、ノード認証情報のローテーション、Platform API Key の再発行、フィッシングへの警戒を求めています。
これは単独の事案ではありません。同じ月に少なくとも9社の AI 開発プラットフォームが侵害を公表し、セキュリティ企業 Wiz はこれを「ブラック・オクトーバー」と呼びました。Chainalysis と WorkOS も AI を使った攻撃を受けたことを認めています。さらに、LiteLLM のリリースパイプライン、Cursor の拡張機能マーケットプレイス上の Claude Code 拡張、Polymarket のサードパーティ製フロントエンドスクリプトが相次いで改ざんされました。
本記事では、まずこれらの事案と共通するパターンを振り返ります。そのうえで「アカウントと認証」「鍵と認証情報」「ソフトウェアサプライチェーン」「監視と訓練」の4つの層に分けて、開発チームや中小企業が事前に実施できる対策を整理します。
1. 事案の振り返り：1か月で起きた8件
10月上旬から11月3日にかけて、AI 開発プラットフォーム、Web3 インフラ、開発ツールで事案が続きました。開発チームに関係の深い8件を、新しい順にまとめます。
| 日付（2026年） | 事案 | 何が起きたか | 漏えい・被害 |
|---|---|---|---|
| 11/3 | Chainstack | 攻撃者は10/26にサードパーティ製コンポーネント経由で開発環境に侵入し、その後本番環境の一部に到達。10/31に検知・遮断 | 組織名、アカウント所有者名、メンバーのメールアドレス、パスワードハッシュ。ノード認証情報のあるシステムにアクセスがあり、漏えい扱いで対応 |
| 10/30 | Chainalysis | 外部の攻撃者が「攻撃的な AI エージェント技術」で社内システムとツールに侵入。11/2から Reactor などを一時停止 | ユーザー ID、氏名、メールアドレス、組織内ロール。平文パスワード、MFA シークレット、セッショントークンへのアクセスは確認されていない |
| 10/30 | WorkOS | 10/30に侵入を検知。範囲は営業・顧客管理系システムに限られ、ARTEX フレームワークとの関連が指摘されている | CRM の連絡先、顧客とのやり取りの記録、営業・サポート会話の要約。本番システムへの影響なし |
| 10/6–10/30 | 「ブラック・オクトーバー」 | 少なくとも9社の AI 開発プラットフォームが侵害を公表：Fireworks AI、Andromeda、Zeabur、Lightning AI、OpenCode、Railway、Warp、CommandCode、Northflank。その後 Brev（NVIDIA）と Trigger.dev も報告 | 攻撃者はプラットフォームに保存された環境変数を狙い撃ち。Wiz が追跡した企業の Bedrock 鍵2本だけで、定価換算10万ドル超の利用。Zeabur はサービス終了を発表 |
| 10/29 | Polymarket | サードパーティのパフォーマンス監視サービス DebugBear のスクリプトが差し替えられ、悪意あるスクリプトがログイン中のセッションを使ってポジションを売却し、資金を送金 | 約270万ドル、700超のウォレット。取引停止に伴う損失分を含め計390万ドルを返金。サードパーティ製フロントエンドコード経由の被害は今年2回目 |
| 10/29 | Claude Code 拡張（Cursor マーケットプレイス） | 改ざんされたバージョン 2.1.313 が Cursor の拡張機能マーケットプレイスで約11時間公開され、自動更新でインストールされ得た | 最大5,000人。攻撃者の SSH 公開鍵を書き込み、リバーストンネルと自動起動を設定。アンインストールしても除去されない。Microsoft 公式マーケットプレイスは影響なし |
| 10/21 | LiteLLM | リリースパイプラインが侵害され、悪意ある 1.107.0 が PyPI に約1時間45分、Docker イメージ（latest タグを含む）に約2時間半公開 | Python 起動のたびに動く情報窃取プログラムとバックドア。クラウド認証情報、AI ツールのトークン、.env、SSH 鍵、ブラウザデータが標的 |
| 10/17〜 | ARTEX 攻撃フレームワーク | マルチエージェント型 AI ペネトレーションフレームワーク（当初はオープンソース、現在は非公開）。CrowdStrike によると、ある国家支援型グループがこれを使い200超の組織を同時に攻撃 | うち9組織で侵入後の活動を確認。手口の一つは、2022年以降一度もローテーションされていない認証鍵を使った管理者トークンの偽造 |
2026年11月4日時点で、多くの事案は調査中です。上記は各社の公表内容とセキュリティメディアの報道に基づいています。
2. 共通パターン：攻撃者が狙うのは認証情報
入口はばらばらでも、狙いはほぼ共通しています。有料サービスを直接呼び出せる、あるいは資産を動かせる認証情報を手に入れ、被害者が気づく前に使い切ることです。
| パターン | 事案での現れ方 | 対応する対策 |
|---|---|---|
| 狙いはコードではなく認証情報 | 「ブラック・オクトーバー」では各プラットフォームの環境変数が狙われた。LiteLLM の情報窃取プログラムは .env、クラウド認証情報、AI ツールのトークンを収集。改ざんされた拡張は、鍵らしき環境変数の名前を送信 | 対策② |
| 入口はサードパーティ | Chainstack はサードパーティ製コンポーネント経由。Railway はビルド基盤での権限昇格と暫定判断。Warp はサードパーティの依存関係を指摘。Polymarket は監視スクリプトの差し替え | 対策③ |
| 漏えいから悪用まで数十分 | Wiz の観測では、ベンダー側で鍵が漏れてから30分以内に最初の呼び出しがあり、数日後に転売ルートで大量に使われた | 対策②・④ |
| 古い認証情報ほど使える | ARTEX の事例では、2022年以降ローテーションされていない鍵で管理者トークンを偽造し、さらに2024年のメール漏えいに含まれていた VPN 鍵で内部ネットワークに侵入 | 対策② |
| 情報漏えいの後にはフィッシング | Chainstack や Chainalysis から漏れた氏名・メールアドレス・組織情報は、標的型フィッシングに十分。AI で作られた偽ログインページは、認証コードやセッションまで奪える | 対策① |
AI によって、攻撃は速く、安くなりました。CrowdStrike は、ARTEX を使えば小さなチームでも多数の侵入を並行して進められ、ある経路が失敗すると別の経路に切り替えると指摘しています。人手で発見して手作業で対処する守り方では、もう間に合いません。そこで本記事が重視するのは事前の設定です。認証情報の権限を小さく、寿命を短くし、悪用されたら自動で警告が出るようにしておきます。
3. 対策①：アカウントと認証
アカウント層の目標は二つです。一度の漏えいの影響を一つのアカウントにとどめること、そしてフィッシングで奪われたものを使えなくすることです。
- サービスごとに別々のパスワードを、パスワードマネージャーで生成する。 Chainstack で漏れたのはパスワードハッシュです。十分に長いランダムなパスワードはオフラインで解読されにくい一方、弱いパスワードや使い回しのパスワードは、解読されると他のサービスへのログインに試されます。
- Passkey や FIDO2 セキュリティキーを使えるところでは使う。 これらはサイトのドメインに紐づいており、偽のドメインでは応答しません。SMS や認証アプリの6桁のコードは、リアルタイムで中継するフィッシングページに転送され得ますが、Passkey はされません。
- 組織単位で二要素認証を必須にする。 Chainalysis も顧客への通知で、まだ有効にしていない組織にすぐ有効化するよう勧めています。
- メンバーと権限を定期的に棚卸しする。 退職者や契約が終了した外部メンバーは当日中に削除し、ロールに応じて最小権限を付与します。共有アカウントは個人アカウントに切り替え、問題が起きたときに誰の認証情報かを追えるようにします。
- 「セキュリティ通知」を受け取ったら、決まった手順で確認する。
- メール内のリンクはクリックせず、公式 URL をブラウザに直接入力してログインする。
- 公式サイトのお知らせ、ステータスページ、信頼できるセキュリティメディアで、事案が実在するか確認する。
- メールヘッダーを確認する。Gmail でメールを開き、右上の ⋮ →「メッセージのソースを表示」（Show original）を選び、SPF、DKIM、DMARC がすべて PASS で、送信元が公式ドメインであることを確かめる。
- まっとうなサービス事業者が、メールでパスワード、トークン、API Key、シードフレーズを求めることはない。求めてきたら、すべてフィッシングとみなす。
- 身に覚えのないパスワードリセットのメールやログイン承認の通知に注意し、自分で操作していなければ「承認」を押さない。
4. 対策②：鍵と認証情報
サードパーティのプラットフォームに預けた鍵は、いつか必ず漏れると想定し、漏れたときの被害を事前に最小限に抑えておきます。本記事で最も重要な章です。
4-1. まず鍵の一覧表をつくる
Chainstack は一度の通知で3種類の認証情報のローテーションを求めました。どの鍵がどこで使われているか分からなければ、ローテーションは社内中の設定ファイルを探し回る作業になります。チームごとに、少なくとも次の列を持つ表を管理することをおすすめします。
| 鍵 | 用途 | 保管場所 | 権限範囲 | 担当者 | 前回ローテーション | ローテーション手順 |
|---|---|---|---|---|---|---|
| ブロックチェーンノードの RPC 認証情報 | 本番の RPC 読み取り | Secrets Manager | 単一ノード | バックエンド担当 | 2026-09-01 | 新しい認証情報を発行 → アプリを更新 → 古い認証情報を無効化 |
| Bedrock 呼び出し用の認証情報 | AI カスタマーサポート | IAM ロール（長期鍵なし） | 指定モデル、us リージョン | バックエンド担当 | 該当なし | ローテーション不要 |
4-2. 最小権限：モデル、リージョン、用途を絞る
Wiz が追跡した盗まれた Bedrock 鍵2本は、権限設定の違いで結果が大きく分かれました。
- 事例 A：鍵が
global.*のクロスリージョン推論を許可していたため、30時間で約80万回呼び出され、スロットリングされたのは約6%だけでした。 - 事例 B：鍵は
us.*の推論プロファイルしか許可していませんでした。転売業者がglobal.*で送った数千件のリクエストはすべて失敗し、その後のトラフィックもリージョンのクォータに阻まれ、失敗した呼び出しのほぼすべてがスロットリングによるものでした。
権限の制限だけで悪用を完全に防げたわけではなく、事例 B でも100万回以上の呼び出しが成功しています。それでも、攻撃を遅らせ、被害の上限を下げる効果はありました。AWS Bedrock の場合、呼び出し用の認証情報には、業務で実際に使うモデルと推論プロファイルだけを許可します（例示です。モデル ID とリージョンは実環境に合わせてください）。
1{
2 "Version": "2012-10-17",
3 "Statement": [{
4 "Sid": "InvokeApprovedModelOnly",
5 "Effect": "Allow",
6 "Action": ["bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream"],
7 "Resource": [
8 "arn:aws:bedrock:us-east-1:123456789012:inference-profile/us.<model-id>",
9 "arn:aws:bedrock:us-*::foundation-model/<model-id>"
10 ]
11 }]
12}原則として、bedrock:* のようなワイルドカード権限は付与しません。開発・テスト・本番で鍵を分け、クラウドや API プラットフォームが IP、送信元、プロジェクト単位の制限に対応していれば、できる限り制限します。
4-3. 長期の鍵はできるだけ使わない
- CI/CD：GitHub Actions から OIDC で AWS IAM ロールや GCP Workload Identity Federation の短期認証情報を取得し、リポジトリの Secrets に長期の Access Key を置かないようにします。
- クラウドサーバー：インスタンスロールやサービスアカウントを使い、IMDSv2 を必須にします。ARTEX の事例の一つでは、XXE 脆弱性を使ってクラウドのインスタンスメタデータサービスにアクセスし、ロールの認証情報を取得していました。IMDSv2 は最初に PUT でトークンを取得する必要があるため、GET リクエストしか送れないこの種の攻撃を防げます。
- 暗号資産の秘密鍵：PaaS の環境変数には置かないでください。SNS では、Railway に保存されていた暗号資産の鍵を使って約37万ドルが盗まれたとの投稿がありました（Wiz による紹介、未確認）。署名は KMS、HSM、MPC などに任せ、ホットウォレットには上限額を設け、高額の送金はマルチシグにします。
4-4. 鍵ごとに上限を設ける
- クラウドアカウントと AI サービスに予算アラート（AWS Budgets、GCP の予算アラート）を設定し、事業者が対応していればハードな利用上限も設けます。
- サービスクォータを、業務に実際に必要な水準まで下げます。事例 B が示すとおり、クォータそのものが損失を止める一線になります。
4-5. ローテーションを30分以内に終えられるようにする
攻撃者は漏えいから30分以内に鍵を試し始めます。ローテーションに丸一日かかるなら、防御線がないのと同じです。
- 無停止ローテーション：新旧の鍵を一定期間同時に有効にし、アプリを切り替えてから古い鍵を無効化します。Chainstack が11月2日にノード認証情報向けに提供を始めたのも、まさにこの仕組みです。
- 一元管理：アプリは実行時に Secrets Manager、Secret Manager、Vault から鍵を読み込み、イメージやビルド設定に鍵を埋め込まないようにします。ローテーションは一か所の変更で済みます。
- 定期ローテーション：周期を決めておき、どこかのベンダーからセキュリティ通知が届いたら、調査結果を待たずに関連する鍵をすぐローテーションします。
4-6. 鍵をコードリポジトリとログに入れない
- pre-commit と CI で gitleaks や trufflehog を実行し、GitHub の Secret scanning push protection を有効にします。
- ログやエラーメッセージに環境変数を出力しないようにし、CI のログでは機密値のマスキングを有効にします。
5. 対策③：ソフトウェアサプライチェーン
サプライチェーン事案の被害者の多くは、普段どおりパッケージをインストールし、拡張機能を更新し、監視スクリプトを読み込んだだけです。守りの要は、「新しいものが入ってくる」段階を遅く、管理でき、追跡できるものにすることです。
5-1. バージョンとハッシュを固定し、latest を使わない
LiteLLM の事案では、Docker の latest や main-stable などのタグが約2時間半にわたって悪意あるイメージを指していました。一方、バージョンを固定していたチームは影響の時間帯から完全に外れていました。
1# Python：ハッシュ付きのロックファイルを生成し、インストール時に検証を必須にする
2pip-compile --generate-hashes requirements.in
3pip install --require-hashes -r requirements.txt
4
5# Node：CI ではロックファイルどおりにだけインストールする
6npm ci
7
8# Docker：本番では可変タグではなく digest でイメージを指定する
9docker pull ghcr.io/your-org/app@sha256:<digest>5-2. 新しいバージョンは数日「寝かせる」
悪意ある LiteLLM 1.107.0 が PyPI に公開されていたのは2時間足らずで、セキュリティ企業は公開から数分で検知しました。依存関係の更新に最低公開期間を設ければ、この種の汚染の大半は避けられます。Renovate の minimumReleaseAge や uv の --exclude-newer で実現できます。緊急のセキュリティパッチは個別に許可します。
5-3. IDE 拡張と開発者の PC
開発者の PC には最も多くの認証情報があるのに、最も管理が行き届いていないことがよくあります。
- 拡張機能は信頼できるマーケットプレイスからだけインストールし、自分のエディタがどのマーケットプレイスを使っているか把握しておきます。Cursor など VS Code 派生のエディタは、Microsoft 公式ではなく、独自またはオープンソースのマーケットプレイスを使っています。
- 拡張機能の自動更新をオフにし、計画的に更新します。VS Code や Cursor の設定に
"extensions.autoUpdate": falseを追加し、使っていない拡張機能は定期的に削除します。 - 本番環境の鍵をシェルの設定ファイルに常駐させないでください。
aws sso loginのような短期セッションや、パスワードマネージャーの CLI による実行時の注入に切り替えます。 - リモートログインが不要な Mac では、「システム設定」→「一般」→「共有」で「リモートログイン」をオフにします。
~/.ssh/authorized_keysに見覚えのない公開鍵がないかも定期的に確認します。改ざんされた Claude Code 拡張は、まさに公開鍵の書き込みと SSH サービスを使ってバックドアを残そうとしました。
5-4. Web サイト上のサードパーティスクリプト
Polymarket の被害は、スマートコントラクトの脆弱性ではなく、ページ上のサードパーティ監視スクリプトが差し替えられ、ログイン中のセッションを使って資金を動かされたことによるものです。
- サイトが読み込むサードパーティスクリプトをすべて洗い出します。ログイン、決済、出金、ウォレット署名のページには、原則として分析・監視系のサードパーティスクリプトを読み込みません。
- バージョンが固定されたスクリプトには SRI を付け、内容が改ざんされたら実行を拒否させます。CSP でスクリプトの読み込み元と外部への通信先を制限します。
<script src="https://cdn.example.com/lib@1.2.3/lib.min.js"
integrity="sha384-<hash>" crossorigin="anonymous"></script>Content-Security-Policy: script-src 'self' https://cdn.example.com; connect-src 'self' https://api.example.com- ただし限界もあります。ある専門家は、今回の悪意あるスクリプトはベンダー自身のドメインと通信していたため、そのドメインを許可する CSP では防げず、更新頻度の高い監視スクリプトは SRI で固定するのも難しいと指摘しています。こうしたスクリプトは、審査済みのコピーを自社でホストするか、機密性の高いページから遠ざけてください。
- サーバー側にも最後の砦を用意します。出金や受取先アドレスの変更など高リスクの操作には再認証や追加の確認を求め、乗っ取られたセッションだけでは完了できないようにします。
6. 対策④：監視と訓練
ここまでの3つの層をすり抜けるものは必ずあります。最後の層は、早く気づき、事前に用意した手順で対処することです。
6-1. 「誰があなたの鍵を使っているか」を見張る
Wiz の2つの事例では、盗まれた鍵は普段、侵害されたベンダーのサーバーから主に呼び出されていました。盗まれた後の最初の呼び出しは住宅用 IP からで、その後数日間は1日十数回〜百数十回の「生存確認」の呼び出しが続き、そのあとで大量の悪用が始まりました。この数日間こそが発見のチャンスです。
- クラウドの API 監査ログ（AWS CloudTrail など）と、AI モデルの呼び出しログを有効にします。
- 次のシグナルにアラートを設定します：想定外の IP やネットワークからの呼び出し、使ったことのないモデルやリージョンの出現、呼び出し量や費用の急増。
- 予算アラートに加えて日次の利用量アラートも設定し、月末の請求書を待たないようにします。
6-2. ベンダーのセキュリティ情報を購読する
利用している各プラットフォームのステータスページ、セキュリティ情報ページ、公式アカウントを一覧にし、担当者を決めて確認します。ベンダーからの通知メールは遅れることも、迷惑メールに振り分けられることもあります。情報源を一つ増やせば、それだけ早く動けます。
6-3. 開発 PC とサーバーに残る永続化の痕跡を定期的に確認する
改ざんされた Claude Code 拡張は SSH 公開鍵を書き込み、macOS では起動項目、Linux では起動時の cron、Windows ではスケジュールタスクを作成しました。定期的に次を確認できます。
1# 見覚えのない SSH 公開鍵
2cat ~/.ssh/authorized_keys
3# macOS の起動項目
4ls ~/Library/LaunchAgents /Library/LaunchAgents /Library/LaunchDaemons
5# Linux の定期実行タスク
6crontab -l6-4. 1ページの対応手順を用意し、四半期ごとに訓練する
ベンダーからセキュリティ通知を受け取ったら、次の順に対応します。
- 公式の経路で、通知が本物か確認する（対策①の5を参照）。
- 鍵の一覧表から、影響を受けるすべての認証情報を洗い出す。
- 手順に沿って一つずつローテーションする。目標は30分以内。
- ベンダーが公表した侵入開始時刻以降の呼び出しログと請求に、異常がないか確認する。Chainstack の場合は10月26日から確認する。
- 今後届くフィッシングメールに注意するよう、チームに周知する。
- 対応の経過を記録し、一覧表と手順書を更新する。
訓練では本番の鍵を1本ランダムに選び、ローテーション完了までの時間を計ります。30分以内に終わらなければ、一覧表かローテーションの仕組みにまだ穴があるということです。
7. 今日からできる10のこと
- Chainstack、Chainalysis、WorkOS、「ブラック・オクトーバー」の各プラットフォームを利用しているか確認し、該当すれば公式の指示どおりに対応する。
- パスワードマネージャーを使い、重要なサービスのパスワードを個別のランダムなものに変える。
- クラウドコンソール、コードホスティング、ドメインレジストラ、業務用メールで Passkey または二要素認証を有効にする。
- 鍵の一覧表をつくり、まず本番環境で最も重要な10本を書き出す。
- ワイルドカード権限の API 鍵を停止し、モデル・リージョン・プロジェクト単位で発行し直す。
- クラウドアカウントと AI サービスに、予算アラートと日次の利用量アラートを設定する。
- CI/CD にある長期の Access Key を確認し、OIDC の短期認証情報に置き換えられるものは置き換える。
- 本番イメージを digest 指定に変え、依存関係のインストールでロックファイルのハッシュ検証を有効にする。
- エディタ拡張の自動更新をオフにし、使っていない拡張を削除する。
- ログイン、決済、出金ページで読み込んでいるサードパーティスクリプトを洗い出す。
ソラナリンク株式会社について
ソラナリンク株式会社（SolanaLink Co., Ltd.）は東京の IT サービス企業で、クラウドソリューション、Web・モバイル開発、IT 運用、AI エージェント導入を提供しています。鍵の棚卸し、クラウド権限の見直し、サプライチェーン対策でお手伝いが必要でしたら、info@solanalink.jp までお気軽にご連絡ください。
参考資料
- Chainstack Reports Production Systems Breach Exposing Customer Data and Password Hashes（The Hacker News、2026-11-03）
- Chainstack updates: November 2, 2026（Chainstack Docs）
- "Black October" for AI Developer Platforms（Wiz、2026-10-30）
- Chainalysis Security Incident Information（Chainalysis、2026-10-30、11-02 更新）
- Chinese Hackers Use AI-Powered ARTEX to Target Over 200 Organizations Worldwide（The Hacker News、2026-10-30）
- LiteLLM release pipeline hacked to distribute info-stealer malware（BleepingComputer、2026-10-22）
- Claude Code extension poisoned with persistent SSH backdoor（Help Net Security、2026-10-30）
- Polymarket Users Lose $2.7 Million in Third-Party Script Hack（Hackread、2026-10-31）
- AI-Generated Fake Login Pages Are Making Account Takeovers Easier（The Hacker News、2026-10-27）
コメント
コメント (0)