対象：アプリ配備のクラウドサービス（PaaS）Zeaburでアプリやデータベースを動かしている開発者・運用者。特に、AIサービスのAPIキー、決済・クラウド・データベースの認証情報を環境変数に入れていた人。本記事はZeaburの公式の初期報告とサービス終了の告知にもとづく解説で、攻撃手順は扱いません。
続報待ち：この記事は公式発表に合わせて更新します
- 対象者
アプリ配備のクラウドサービス（PaaS）Zeaburでアプリやデータベースを動かしている開発者・運用者。特に、AIサービスのAPIキー、決済・クラウド・データベースの認証情報を環境変数に入れていた人。
- 影響が確認された範囲表で見る ↓
- プラットフォームデータベースの環境変数
- アカウントの情報
- zSendのAPIキー
さらに2件
- プラットフォームのAccess Token
- 同社が「GCPのDedicated Server」と呼ぶ区分
- 未確認事項
- 攻撃者が最初の認証情報を手に入れた経路
- 共有クラスターのデータベースから実際に持ち出された量
- バックアップや保存ファイルがダウンロードされたか
さらに1件
- 同社が「HetznerとDigitalOceanのDedicated Server」と呼ぶ区分向けの漏れたトークンが使われたか
- 今やること手順を見る ↓
- 環境変数に入れた秘密を、発行元ですべて失効させる
- 共有クラスターの利用者は、データベースの中のパスワードも変える
- ZeaburのAccess TokenとzSendのAPIキーを作り直す
さらに4件
- GitHubを連携していたなら、10月15日の監査ログを確かめる
- 10月14日以降の利用量と請求を確かめる
- 損害が出たら、2026年11月30日までに申請する
- 対象のDedicated Serverは、侵害されたものとして扱う
- 最終確認日時
- 2026年10月31日時点
発表の続報予定と確認の記録
10月19日の報告には「調査は継続中であり、本記事は進捗に応じて更新します」とあります。10月31日に確認した時点で、ページの日付は10月19日のままです。同社のブログでその後に出たのは、返金と損害の申請についての10月22日のお知らせだけで、調査の続報ではありません。
Zeaburの利用者が今日やること
環境変数に入れた秘密を、発行元ですべて失効させる
対象は、APIキー（AIサービス・決済・メール配信など）、クラウドのキー、データベースのパスワード、署名・暗号化の鍵です。同社が示す順番は、まず発行元のサービスで古い値を失効させる、次に新しい値を作り、Zeaburに設定して再デプロイ、です。
Zeabur上で変数を消したり書き換えたりするだけでは、すでに誰かが持っている写しは止まりません。8月の事案のあとに差し替えた値も対象です。同社は、8月の差し替えが今回使われた認証情報を含んでいなかったとしています。
共有クラスターの利用者は、データベースの中のパスワードも変える
同社によれば、Zeabur上の環境変数を変えても、データベースの中のパスワードは変わりません。パスワードを変えても、すでに漏れたデータは取り消せません。データベースに自分のサービスの利用者のパスワードハッシュ、ログインのセッション、トークンを保存しているなら、それらも失効させて作り直してください。
同社はほかに次の対応を求めています。
- n8n：n8nの暗号化キーを替え、n8nに保存した外部サービスの認証情報をすべて作り直す
- new-api/one-api：上流のAIサービスのキーを失効させ、アクセストークンを作り直す
- PostgreSQL：心当たりのないロール・関数・トリガー・定期ジョブ・拡張がないか確かめる。迷うなら新しいデータベースを作り、データだけを取り込む
- 台北（tpe1）と香港（hkg1）のリージョン：データベースのバックアップの中身は漏れたものとして扱う
ZeaburのAccess TokenとzSendのAPIキーを作り直す
同社は全ユーザーをログアウトさせ、プラットフォームのAccess Tokenをすべて失効させたとしています。もう一度ログインし、Access Tokenの管理画面で新しいトークンを作り、心当たりのないリクエストがないか確かめてください。zSendの利用者はAPIキーを作り直す必要があります（566件すべて失効済み）。
GitHubを連携していたなら、10月15日の監査ログを確かめる
同社によれば、ZeaburのGitHub Appの秘密鍵が読み取られ、10月15日18:54（UTC）に差し替えられました。現時点で使われた形跡は見つかっていないとしています。同社は、10月15日15:05〜18:54（UTC。日本時間16日0:05〜3:54）のZeabur GitHub Appによる操作を、GitHubの監査ログで確かめるよう求めています。見る点は、想定外のクローンやプッシュ、新しいデプロイキー、変更されたWebhookです。
10月14日以降の利用量と請求を確かめる
キーを置いていた各サービスの利用量と請求を、2026年10月14日からさかのぼって確かめてください。同社は、この日は分かっている最初の使用日で、それ以前に漏れていないことを意味しないとしています。同社が「GCPのDedicated Server」と表記するサーバーの利用者は9月1日までさかのぼります。盗まれたAIのキーがすぐ請求につながる理由は 盗まれたAPIキーとアカウントの停止 を参照してください。
損害が出たら、2026年11月30日までに申請する
同社の10月22日のお知らせによれば、10月の事案による損害の申請は、Zeabur Supportの別のチケットで2026年11月30日までに出す必要があり、期限までに出された申請だけを受け付けます。必要なのは、対象のアカウントとサービス、漏れたキーや認証情報の種類、事案の期間の外部サービスの請求書か利用記録です。残高の返金とは別の手続きです。
対象のDedicated Serverは、侵害されたものとして扱う
同社が「GCPのDedicated Server」と表記するサーバーについて、同社は侵害されたものとして扱うよう求めています。データをバックアップしてサーバーを作り直すのが、残されたものを取り除く最も確実な方法だとしています。すぐ作り直せない場合の最低限の対応は、心当たりのないSSHの鍵を消す、アカウント・定期ジョブ・サービスを確かめる、rootのパスワードを変えてSSHのパスワードログインを止める、サーバー上の認証情報をすべて差し替える、です。確かめる痕跡は同社の報告に載っているので、公式ページで確認してください。
同社が「HetznerとDigitalOceanのDedicated Server」と呼ぶ区分のサーバーについては、10月14日以降にrootのパスワードの再設定やOSの再インストールがなかったかを、各事業者の管理画面で確かめるよう求めています。
何が起きたのか（Zeaburの報告より）
以下は、Zeaburが2026年10月19日に公開した初期報告（日本語版あり）にもとづきます。時刻はすべてUTC（日本時間は9時間足す）です。
2026年8月
Zeaburで別のセキュリティ事案。同社は、そのあとの差し替えが10月に使われた認証情報を含んでいなかったとしている。10月14日 01:36
攻撃者がZeaburの内部のクラウドのキーを初めて使用。続いて共有クラスターにアクセス。10月15日 13:56
利用者からの報告を受けて、Zeaburが調査を開始。10月15日 16:10〜16:47
攻撃者がプラットフォームデータベースを読み取る（同社が確認）。10月15日 20:25
ログイン用の署名鍵を差し替え、全ユーザーをログアウト。10月15日 21:05
現時点で確認された攻撃者の最後の活動。10月17日
Zeaburが2026年12月31日でのサービス終了を発表。10月19日
Zeaburが本件の初期報告を公開。10月22日
Zeaburが本件の損害の申請期限を2026年11月30日とし、12月31日にサービスのデータを削除すると告知。
Zeaburに保存：読み取られた
Zeaburのプラットフォームデータベースにあった環境変数。8月のあと移行していないプロジェクトを含む
8月のあと自分のDedicated Serverへ移行
データベースが読み取られた範囲の外。ただしサーバー自体が対象なら、その上の秘密は差し替えが必要
同社はどちらの場合も全員に差し替えを求めています。この区別は、漏えいの確からしさが違うというだけです。
- 何が起きたか
- 攻撃者が流出したZeaburの内部認証情報を使い、共有クラスター、一部のDedicated Server、内部システムに侵入し、プラットフォームデータベースを読み取った
- 読み取られた情報
- 環境変数（3,218,965件）、アカウントの情報（321,810件）、zSendのAPIキー（566件）。ほかに、元に戻せないハッシュだけで保存されたAccess Token（11,536件、すべて失効）
- ほかのシステム
- 共有クラスターの865のデータベースのコンテナ内でコマンドが実行された。同社が「GCPのDedicated Server」と呼ぶ区分の101台にrootでのログインを確認
- 原因（同社）
- 長期間有効な管理用認証情報が平文で保存され、インターネットから使える状態だった。同社は根本原因がZeabur側にあるとしている
- 対応
- 使われた認証情報の失効、管理画面とサーバーへのインターネットからのSSHの遮断、全ユーザーのログアウト、Access Tokenの全失効
- 補償
- 本件による外部のAPIキーやクラウドのアカウントの追加請求は、サポートのチケットで2026年11月30日まで申請できる（10月22日のお知らせ）
分かっていること・分かっていないこと
2026年10月31日時点の状態です。同社は「確認済み」（ログに直接の記録がある）、「推定」（時期と内容は一致するが直接の記録がない）、「確認できない」（確かめられる記録がなく、流出したものとして扱う）、「推測」（間接的な証拠だけに支えられた説明）の言葉を使っています。状態欄はそれに合わせました。続報が出たら状態欄を更新します。
| 項目 | 報告の内容 | 状態 |
|---|---|---|
| プラットフォームデータベースの環境変数 | 3,218,965件（名前と値）を読み取り | 確認済み（同社） |
| アカウントの情報 | 321,810件。メール・ユーザー名・電話番号など、プロジェクトの情報を含む | 確認済み（同社） |
| zSendのAPIキー | 平文で保存の566件、すべて失効済み | 確認済み（同社） |
| プラットフォームのAccess Token | 元に戻せないハッシュだけで保存の11,536件、すべて失効済み | 確認済み（同社） |
| 共有クラスターの環境変数・秘密 | 9リージョン。一部は確認済み、残りは流出したものとして扱う | 一部確認済み・残りは確認できない（同社） |
| 共有クラスターのデータベースの中身 | 865のデータベースでコマンドを実行。持ち出された量は確認できない | 推定（同社） |
| 同社が「GCPのDedicated Server」と呼ぶ区分 | 101台（92ユーザー）でrootのログインを確認 | 確認済み（同社） |
| データベースのバックアップ（台北tpe1・香港hkg1） | ダウンロードされたかは確認できない。別に同社は、侵害されたホスト上の証拠から、10月15日15:42（UTC）に攻撃者が利用者のデータベースのバックアップを取得したことを確認したとしている | 確認できない（同社） |
| 同社が「HetznerとDigitalOceanのDedicated Server」と呼ぶ区分 | 管理用のトークンが漏えい。使われたかは確認できない | 確認できない（同社） |
| 2段階認証・パスキーの情報 | 統計の照会だけで、中身を読んだ記録はない | 中身の読み取り記録なし（同社） |
| 最初の認証情報を得た経路 | 確認できない。8月とのつながりは未証明の推測 | 確認できない（同社） |
| 漏れたキーの悪用 | 10月16日に利用者のAIサービスのキーで約1,107件のリクエスト。本件の流出によるものかは推測の段階 | 推測（同社） |
読み方：「確認できない」でも差し替えは必要
同社は、不正アクセスを否定できないデータは漏れた可能性がある前提で対応するとしています。自分の秘密については、「確認済み」「推定」「確認できない」のどれでも取るべき行動はほぼ同じです。どれも失効させて差し替えます。
環境変数が漏れると何が起きうるか
一般に、環境変数から取られた秘密は次のように悪用されえます。今回これがすべて起きたという意味ではありません。
- AIサービスのAPIキー：他人があなたの契約でリクエストを送り、請求はあなたに来る。同社は、攻撃者が主にすぐ使えるキー、特にAIサービスのキーを探していたと観察している
- データベースのパスワード・接続文字列：アプリのデータの閲覧や書き換え（自分のサービスの利用者の情報を含む）
- 署名・暗号化の鍵：セッションのトークンの偽造や、アプリが守っているデータの復号
- クラウド・決済のキー：費用のかかるリソースの作成や呼び出し
過去の例では、Railwayの環境変数の事案で、配備サービス側が漏れた可能性のあるキーの一覧を発行元に送り、失効を依頼しました。今回も同じ流れになるとは限らないので、キーは自分で失効させてください。
運営者が見直すこと：同社が公表した原因から
以下は、同社自身が挙げた原因と欠けていた点から言えることです。Zeaburをさらに評価するものではありません。
- 管理用トークンに有効期限を付け、管理画面をインターネットに出さない。 同社によれば、クラスターの管理用トークンには期限がなく、2024年1月の作成以来差し替えられておらず、管理画面はインターネットから届く状態でした。
- 事案のあとは、漏れたと確認できたものだけでなく、読まれえた認証情報をすべて差し替える。 同社は、8月の差し替えが10月に使われた認証情報を含んでいなかったとしています。
- バックアップに平文の秘密を入れず、バックアップのキーを分けて保管する。 同社によれば、クラスターのバックアップにすべての秘密が入っており、対応中に差し替えたキーが後のバックアップに取り込まれました。
- 秘密の大量読み取りに通知を付ける。 同社によれば、10月14日の16時間を超える活動で通知は一度も出ず、発覚は利用者の報告がきっかけでした。
自分のアプリでは、配備サービスに保存しない秘密が一番安全です。有効期限の短い認証情報や、アプリが実行時に読む別の秘密の保管場所を使う方法があります（.envとAPIキーは何が危ないのか）。
出典（公開情報）
本記事の事実は以下の公開情報にもとづきます。同社が確認していない侵入経路は推測せず、侵害の痕跡（IoC）の値は載せていません。
- Zeabur「Zeabur 2026年10月のセキュリティインシデント（初期報告）」（2026年10月19日） — zeabur.com（英語版 zeabur.com）
- Zeabur「Zeabur service migration, refunds, and security incident claims」（2026年10月22日、英語） — zeabur.com
- Zeabur「Zeabur is shutting down: what happens next」（2026年10月17日、英語） — zeabur.com
更新履歴
2026-10-31：初版。Zeaburの10月19日の初期報告、10月17日のサービス終了の告知、10月22日の損害の申請についてのお知らせにもとづく。10月31日の時点で、同社のブログに調査の続報はない。続報が出たら本記事を更新します。
次に読む
- 同じ型の事案：Railwayの環境変数が漏れた可能性（2026年10月） ／ OpenCode Consoleへの不正アクセス（2026年10月）
- AIのキーが狙われる理由：AIを使ったサイバー攻撃の対策 ／ 盗まれたAPIキーとアカウントの停止
- 漏れたキーが使える状態で残る問題：漏れた認証情報が有効なまま残る問題
- 2026年の他の事案：情報漏えい・サイバー攻撃の一覧（国内・海外）