対象：Chainstackのノード・APIを使う開発者、dAppの運営者、組織の管理者。本記事は同社の公式発表にもとづく解説で、攻撃の手順は扱いません。
続報待ち：この記事は公式発表に合わせて更新します
- 対象者
Chainstackのノード・APIを使う開発者、dAppの運営者、組織の管理者。
- 影響が確認された範囲表で見る ↓
- 不正アクセスの期間
- 本番環境への到達
- 顧客アカウント情報のデータベース
さらに1件
- 調査
可能性があるとされた項目
- 組織名、アカウント保有者名
- 組織メンバーのメールアドレス
- パスワードのハッシュ
さらに1件
- ノード認証情報
- 未確認事項
- 対象になった顧客の数
- パスワードのハッシュの方式（アルゴリズム）
- 第三者のコンポーネントの内容と侵入の経緯
さらに2件
- ノード認証情報が実際に読まれたか
- 不正利用（二次被害）の有無
- 今やること手順を見る ↓
- パスワードを変更する
- ノード認証情報を再発行する
- プラットフォームAPIのキーを再生成する
さらに3件
- 埋め込んだエンドポイントとキーを探して差し替える
- 利用量と請求に身に覚えのない動きがないか確かめる
- Chainstackを名乗る連絡は、リンクを開かずに確かめる
- 確認先（出典）出典の一覧 ↓
- Chainstack「Incident report: what happened and what customers need to do」（英語、2026年11月3日付、11月4日に確認）
- 最終確認日時
- 2026年11月4日時点
発表の続報予定と確認の記録
同社の発表は11月3日付で、新しい情報があれば更新するとしています。11月4日に発表ページの本文を確認し、11月3日付から更新は見当たりませんでした。同社は調査を11月2日に終えたとしています。
Chainstackの利用者が今日やること
パスワードを変更する
同社は、パスワードを変更するよう求めています。同じパスワードを使い回した他のサービスも変えるよう求めています。
- 当サイトの補足：パスワードマネージャーで、サービスごとに別のパスワードにする（パスワードマネージャーの選び方）
- 当サイトの補足：二段階認証が使えるなら有効にする。発表には書かれていません
ノード認証情報を再発行する
同社は、ノード認証情報の再発行を求めています。コンソールから自分で行え、再発行を終えるまでは現在のエンドポイントが使えるため、停止は生じないとしています。手順は同社の文書で案内されています。
- 当サイトの補足：新しい認証情報を先にアプリへ入れ、動作を確かめてから、古い方を無効にする流れになる
プラットフォームAPIのキーを再生成する
プラットフォームAPIを使っている場合は、APIキーを再生成するよう求めています。使っているCI/CD、自動化のスクリプト、運用ツールの設定も差し替えます。使っていないキーは作り直さず、削除します（当サイトの補足、環境変数とAPIキーの基本）。
埋め込んだエンドポイントとキーを探して差し替える
ノードのエンドポイントは、認証情報つきのURLの形で、アプリのコード、設定ファイル、CIの変数、フロントエンドに入っていることがあります。当サイトの見方：フロントエンドに埋め込んだURLは、閲覧者の誰にでも見えるため、再発行のあとにビルドし直して配り直すまでは、古い認証情報が公開物に残ります。
- 設定、CIの秘密変数、コンテナの環境変数、リポジトリの履歴に古いURLが残っていないか探す
- 公開済みのフロントエンド（ビルド成果物、ソースマップ）を再ビルドして配り直す
- サーバー経由の中継に切り替えられる箇所は、認証情報をブラウザに渡さない形にする
利用量と請求に身に覚えのない動きがないか確かめる
同社は、ノード、コンソール、APIが改変されたことはなく、サービスは継続したと説明しています。それでも、認証情報が使われた場合に備え、当サイトは次を勧めます。
- ノードへのリクエスト数、呼び出し元、使われたメソッドが、いつもと違わないか
- 請求額が急に増えていないか
- 組織のメンバーに、見覚えのない人や権限がないか
Chainstackを名乗る連絡は、リンクを開かずに確かめる
同社は、フィッシングに注意するよう求め、パスワード、トークン、キーをたずねることはないとしています。メールのリンクは使わず、自分で公式のコンソールや発表ページを開いて確かめます。フィッシングとは
① コンソールで認証情報を再発行する
完了するまで、現在のエンドポイントは使える（同社）
↓
② アプリ・CI・フロントエンドを新しいものに差し替え、動作を確かめる
↓
③ 古い認証情報が使われなくなったことを確かめる
公開済みのフロントエンドに旧URLが残っていないか
何が起きたのか（Chainstackの発表より）
以下は、同社が2026年11月3日付で公表した、利用者向けの事故報告にもとづきます。
2026年10月26日
外部の攻撃者が、開発環境にアクセスした（同社の説明）10月29日
攻撃者が、本番環境の一部にアクセスした（同社の説明）10月31日
同社が侵入を検知し、同日中にアクセス経路を遮断した（同社の説明）11月2日
同社が調査を終え、事故を終結とした（同社の説明）11月3日
発表ページを公開。全顧客にメールで知らせているとする11月4日
当サイトが発表ページの本文を確認。11月3日付から更新は見当たらず
- 入口
- 外部の攻撃者が、第三者のコンポーネントを通じて、インフラの一部にアクセスした。コンポーネントの内容は書かれていない
- 位置づけ
- 同社は、10月下旬に報じられた、AIを使った広範な攻撃キャンペーンの一環と評価している。同時に、自社の環境で起きたことへの責任は変わらないと書いている
- 露出した可能性がある情報
- 組織名、アカウント保有者名、組織メンバーのメールアドレス、パスワードのハッシュ（顧客アカウント情報のデータベース）。ハッシュの方式は書かれていない
- ノード認証情報
- 認証情報を保管するシステムにアクセスされた。読まれた証拠はないが、露出したものとして扱う
- 含まれないもの
- 決済手段の情報（同社は保存していない）。ノード、コンソール、APIの改変はなく、サービスは継続した
- 同社の対応
- アクセス経路の遮断、システムの強化、全顧客へのメール連絡。利用者へは、パスワード変更、ノード認証情報の再発行、プラットフォームAPIキーの再生成、フィッシングへの注意を求めている
分かっていること・分かっていないこと
2026年11月4日時点の状態です。続報が出たら、この表を書き換えます。
| 項目 | 発表の内容 | 状態 |
|---|---|---|
| 不正アクセスの期間 | 2026年10月26日（開発環境）〜10月31日（検知・遮断） | 確定（同社） |
| 本番環境への到達 | 10月29日に本番環境の一部にアクセスされた | 確定（同社） |
| 顧客アカウント情報のデータベース | 攻撃者がアクセスした | 確定（同社） |
| 組織名、アカウント保有者名 | 露出した可能性がある | 可能性（同社） |
| 組織メンバーのメールアドレス | 露出した可能性がある | 可能性（同社） |
| パスワードのハッシュ | 露出した可能性がある。方式は書かれていない | 可能性（同社） |
| ノード認証情報 | 保管するシステムにアクセスされた。読まれた証拠はないが、露出したものとして扱う | 可能性（同社） |
| 決済手段の情報 | 同社は保存していないため、露出していない | 含まれない（同社） |
| ノード、コンソール、APIの改変 | 改変はなく、サービスは継続した | 含まれない（同社） |
| 対象になった顧客の数 | 記載なし。全顧客にメールで知らせているとする | 記載なし |
| 侵入の入口 | 第三者のコンポーネント。内容は書かれていない | 記載なし（内容は非公表） |
| 不正利用（二次被害） | 記載なし | 記載なし |
| 調査 | 11月2日に終え、事故を終結とした。新しい情報があれば更新する | 確定（同社） |
「可能性」と書く理由
同社は、顧客アカウント情報について、露出した可能性があると説明しています。ノード認証情報も、読まれた証拠はないが露出したものとして扱う、という書き方です。当サイトは、同社の言葉どおりに状態を分けています。実際に持ち出されたかは、発表からは分かりません。
アカウント情報とノード認証情報で何が起きうるか
以下は、この項目の組み合わせから一般に起きうることで、本件で起きたと同社が公表しているものではありません。
- 組織名＋アカウント保有者名＋メンバーのメールアドレス：同社や取引先を装った、本物らしい連絡の材料になる
- パスワードのハッシュ：ハッシュは元のパスワードそのものではありませんが、弱いパスワードや使い回しのパスワードは、後から推測されるおそれがある。方式が書かれていないため、強さは判断できない。変更が先決です（パスワードのハッシュ化とは）
- ノード認証情報：エンドポイントを使うための認証情報で、持っている人は利用者になりすましてリクエストを送れる。利用量や請求に影響しうる。フロントエンドに埋め込んでいれば、閲覧者にも見える点は変わらない
- 使い回しのパスワード：他のサービスで同じパスワードを使っていれば、そちらも変える必要がある。パスワードが漏れたか確かめる方法
開発者・運営者が見直すこと
侵入の入口は第三者のコンポーネントとしか公表されていません。ここでは、公表された事実（認証情報を保管するシステムにアクセスされた、再発行が停止なしにできる）から言える、一般的な見直しの点だけを挙げます。
- 再発行できる作りにしておく：認証情報をコードに直接書かず、環境変数や秘密情報の管理の仕組みから渡す。差し替えが1か所で済み、今回のような連絡が来た日に動ける
- ブラウザに渡す認証情報を減らす：フロントエンドに埋め込んだURLは公開物に残る。サーバー経由の中継や、利用元を絞れる機能（提供されている場合）を使う。ベンダーに機能があるかは、各社の文書で確かめる
- キーを用途ごとに分ける：環境（開発・本番）やアプリごとに別の認証情報にすると、再発行の影響が小さい（環境変数とAPIキーの基本）
- ベンダーの管理画面を守る：二段階認証が使えるなら必須にし、ログイン・キー作成の通知を有効にする（多要素認証の選び方）
これらは一般的な見直しの点で、同社や利用者がこれらを行っていなかったという意味ではありません。
出典（公開記録）
本記事の事実関係は、以下の公開情報にもとづきます。公表されていない入口や、持ち出されたデータの範囲は推測していません。
- Chainstack「Incident report: what happened and what customers need to do」（英語、2026年11月3日付、11月4日に確認） — chainstack.com
更新履歴
2026-11-04：初版。同社の事故報告（2026年11月3日付）にもとづく（11月4日に確認、それより新しい更新は見当たらず）。
次に読む
- 開発者向けサービスの新しい事案：認証局DigiCertの社内システムへの不正アクセス
- 開発者向け基盤の新しい事案：WorkOSの社内営業用アプリへの不正アクセス
- APIキー・秘密情報の管理：環境変数とAPIキーの基本 ／ 漏えいした認証情報が失効しないまま使える問題
- 同種の事案：PingCAP（TiDB Cloud）の不正アクセス、Railwayの秘密情報の露出、Northflankの事故とAPIキー
- 詐欺メッセージへの備え：フィッシングとは
- アカウントを守る：多要素認証の選び方
- 2026年の他の事案：情報漏えい・サイバー攻撃の一覧（国内・海外）