Zeabur 2026年10月のセキュリティインシデント（初期報告）

本記事の時刻はすべて協定世界時（UTC）で表記しています。調査は継続中であり、本記事は進捗に応じて更新します。

概要

• 何が起きたのか： 2026年10月14日から15日にかけて、攻撃者は流出したZeaburの内部認証情報を使用して、共有クラスター、一部のDedicated Server、Zeaburの内部システムに侵入し、最終的にプラットフォームデータベースを読み取りました。
• 遮断済みの侵入口： 攻撃者が使用したクラスター管理トークン、AWSとGCPのキー、内部ネットワークのノードはすべて失効または削除済みで、管理インターフェースとサーバーへのインターネットからのSSHは遮断しました。すべてのユーザーをログアウトさせ、プラットフォームのアクセストークンもすべて失効させています。現在の記録では、攻撃者の最後の活動は10月15日 21:05です。
• 影響を受ける対象： 主に共有クラスター上のサービスとGCPのDedicated Serverです。Zeaburのプラットフォームデータベースに保存されていた環境変数も読み取られました。8月以降、案内に従って環境変数をご自身のDedicated Serverに移行したプロジェクトでは、それらの変数はプラットフォームデータベースが読み取られた範囲に含まれません。
• お客様に必要な対応： 流出したデータは引き続き悪用される可能性があります。8月のインシデント後にすでに差し替えた場合でも、Zeaburに保存しているすべてのパスワードとキーを差し替えてください。手順はお客様に必要な対応をご覧ください。
• 根本原因： 本インシデントの根本原因はZeaburにあります。長期間有効な管理用認証情報が平文で保存され、インターネットから使用できる状態でした。詳しくは発生の原因をご覧ください。
• 8月のインシデントとの関係： 8月のローテーションは、今回使用された認証情報を対象にしていませんでした。一方、8月の案内に従って環境変数を移行したプロジェクトは、プラットフォームデータベースからの流出を免れました。詳しくは8月のインシデントとの関係をご覧ください。

本記事の用語：「確認済み」はログに直接の記録があることを、「推定」は時期と内容は一致するものの直接の記録がないことを、「確認できない」は確認できる記録がないことを表します。確認できないものは、すべて流出したものとして扱っています。「推測」は間接的な証拠のみに支えられた可能性のある説明を表し、未証明の推測にまとめて記載しています。

何が起きたのか

攻撃者は2つの経路をたどり、最終的にZeaburの内部ネットワークで合流しました。

経路A：共有クラスターとAWS

1. 10月14日 01:36から攻撃者はZeabur内部のAWSキーを、01:40から共有クラスターの管理トークンを使用しました。これらの認証情報は、Zeaburのプライベートな設定リポジトリに平文で保存されていました。攻撃者がこれらをどのように取得したかは、現時点で確認できない状態です。当社は、8月のインシデントで流出したGitHub Appの秘密鍵が関係していると推測しています。未証明の推測をご覧ください。
2. 共有クラスターの管理インターフェースは当時インターネットに公開されており、管理トークンにも有効期限がありませんでした。このため攻撃者は、外部から9つのリージョンの共有クラスターにアクセスできました。
3. 01:51から、攻撃者は一部のシステムシークレットを読み取りました。12:39からは、範囲が環境変数を含むすべてのサービスの設定とシークレットに広がりました。完全な読み取り記録があるリージョンでは、内容が読み取られたことを確認しています。その他のリージョンは記録が欠けているため、すべて流出したものとして扱っています。
4. 13:40から、攻撃者はユーザーのデータベースのコンテナ内で読み取りコマンドを実行しました。まず少数のnew-api／one-apiに対して行い、15:41からn8nを大量に読み取り、16:50から一部のPostgreSQLをテーブルごとに読み取りました。最後のコマンドは17:04です。攻撃者がコマンドを実行したデータベースサービスは計865個ですが、すべてのコマンドが成功したわけではありません。
5. 攻撃者は、クラスター内にあった別の権限過大なキーを使用して、旧クラスターのバックアップを読み取りました（推定）。バックアップには、Zeaburのシークレット管理サービスを読み取れるキーが含まれていました。
6. 10月15日 14:52から16:51にかけて、攻撃者は約53件の本番環境シークレットを読み取りました（確認済み）。その中には、内部ネットワークの管理用認証情報、プラットフォームデータベースのアカウント、GitHub Appの秘密鍵が含まれていました。

経路B：GCPのDedicated Server

1. 10月14日 13:40から、攻撃者はZeaburがGCP上で管理するDedicated Server計101台にrootとしてログインしました。
2. これらのサーバーの初期化設定には、rootパスワードが平文で保存されていました。攻撃者は、この設定を読み取れる古いGCPキーを保持していました。当社は、攻撃者がこのキーでパスワードを取得したと推定しています。
3. 10月15日 14:26から、攻撃者は古いGCPキーでサーバーの設定を変更し、自身のSSH鍵を追加しました。15:05には、シークレット管理サービスから本番環境のGCPキーをさらに1つ取得しています。当社が17:17に古いキーを無効化した後、攻撃者は17:28にこのキーに切り替えて再びSSH鍵を追加しましたが、当社は17:31にこのキーも無効化しました。10月14日のGCPサーバーへの最初のログインは、10月15日に本番環境シークレットが読み取られた最初の既知の記録より前に発生しています。後者を前者の起点と記述することはできません。
4. それ以前の9月1日から5日にかけて、出所不明の送信元が同じ一群のサーバーにrootパスワードでログインしており、9月5日当日は約98台でした。同一の攻撃者かどうかは、現時点で確認できない状態です。

2つの経路の合流

1. 10月15日 15:30、攻撃者は侵入したGCPサーバーの1台で、経路Aで取得した内部ネットワークの管理用認証情報を使用し、1つのノードをZeaburの内部ネットワークに参加させました。
2. 内部ネットワークのルールでは、この種のノードからプラットフォームデータベースへの接続が許可されていました。16:10から16:47にかけて、攻撃者は内部の読み取り専用アカウントでプラットフォームデータベースを読み取りました（確認済み）。当社は内部ネットワーク両端の接続記録とデータベースのログを突き合わせました。この期間の29件のデータベース接続はすべてこのノードに対応しており、接続内のログインとクエリも一件ずつ追跡でき、操作記録は計8,903件でした。
3. 17:58、当社はこのノードを削除しました。

インシデントの経路

2つの経路は内部ネットワークで合流しました。矢印の横は、各段階で攻撃者が利用した認証情報または不備です。

経路A　共有クラスターとAWS

起点

AWSキーとクラスター管理トークンを保持

取得方法は確認できない

管理トークンに有効期限がなく、管理インターフェースがインターネットに公開

9つのリージョンの共有クラスター

すべてのサービスの環境変数、865個のデータベースコンテナ

推定：権限過大なキーで旧クラスターのバックアップを読み取り

AWS

シークレット管理サービスのキー

確認済み：本番環境シークレットを読み取り

Zeaburシークレット管理サービス

約53件の本番環境シークレット

内部ネットワークの管理用認証情報とデータベースのアカウントを含む

経路B　GCPのDedicated Server

起点

古いGCPサービスアカウントキー1つ

流出元は確認できない

推定：初期化設定内のrootパスワードを読み取り

GCPのDedicated Server

101台のサーバーのroot権限

侵入したサーバー上で、内部ネットワークの管理用認証情報を使ってノードを参加

Zeabur内部ネットワーク

本番環境の権限を持つノード1つ

内部ネットワークのルールが接続を許可し、内部の読み取り専用アカウントでログイン

Zeaburプラットフォームデータベース

Zeaburに保存されている環境変数、アカウント、プロジェクトのデータ

インシデント対応中にローテーションした一部の認証情報が、その後も不正に使用されました。 Zeaburのクラスターの日次バックアップにはすべてのシークレットが保存されており、攻撃者は10月15日 15:04にバックアップのアクセスキーを読み取っていました。当社が15:40に差し替えた新しいキーは16:00のバックアップに含まれ、攻撃者は20:30にそれを使用しました。当社は18:51にバックアップのアクセスキーを削除し、21:47に影響を受けた認証情報を再度ローテーションしました。新しいキーがバックアップに含まれ、その後使用されたことは確認済みです。攻撃者がこのバックアップをダウンロードしたかどうかは推定です。攻撃者は18:51より前にバックアップを取得していた可能性があるため、20:30の使用は、18:51以降もダウンロードが可能だったことを意味しません。

影響を受けたデータ

プラットフォームデータベース。 10月15日 16:10から16:47にかけて、攻撃者は上表のデータを読み取りました。アカウントのデータには、メールアドレス、ユーザー名、電話番号など、プロフィールページ上の情報が含まれます。攻撃者は、環境変数と設定ファイルからAPIキーと秘密鍵も検索しました。コマンドの内容とその後の行動から見ると、攻撃者は主にそのまま使用できるAPIキー、特にAIサービスのキーを探していました。攻撃者はプラットフォームデータベースでキーを検索し、n8nとnew-api／one-apiの認証情報を大量に読み取り、ZeaburのAWSキーでAmazon Bedrockの呼び出しも試みています。これは攻撃者の意図についての観察にすぎません。攻撃者はアカウントのデータも読み取っており、当社は読み取られたすべてのデータを流出したものとして扱っています。二要素認証とパスキーのテーブルについては統計情報が照会されたのみで、内容が読み取られた記録はありません。当社はすべてのユーザーのプラットフォームのアクセストークンを失効させており、古いトークンはいずれも使用できなくなっています。

移行済みの環境変数は、プラットフォームデータベースが読み取られた範囲に含まれません。 8月のインシデント後、ZeaburはDedicated Serverをご利用のお客様に向けて、認証情報のローテーション、Zeaburに保存している環境変数と設定ファイルの削除、およびご自身のサーバーへのワンクリック移行についての案内と機能を提供しました。移行を完了したプロジェクトでは、これらのデータはお客様のサーバー上にのみ保存され、Zeaburは保持していないため、今回プラットフォームデータベースから読み取られたデータには含まれません。移行していないプロジェクトでは、環境変数がZeaburに保存されたままであり、今回読み取られました。これはホストへの侵入による流出を否定するものではありません。侵入されたGCPのDedicated Serverには、引き続き下記の対応をお勧めします。

アカウントのなりすまし。 攻撃者はログイン用の認証情報を発行するためのキーを読み取っており、当社は攻撃者がこれを使ってログイン用の認証情報を偽造したと推定しています。攻撃者がプラットフォームのアクセストークンを大量に読み取ったのは16:47になってからであり、しかもトークンはハッシュ値のみが保存されているため、16:12に始まったなりすましは説明できません。10月15日 16:12から17:19にかけて、攻撃者は2つのアカウントになりすましてZeabur APIを呼び出し、アカウントとプロジェクトの一覧を読み取りました。そのうち1つはZeabur従業員のアカウントです。これらのリクエストでリソースが変更されたことはありません。当社は20:25に署名キーをローテーションし、すべてのユーザーをログアウトさせました。

共有クラスターのデータベース。 攻撃者は865個のデータベースのコンテナ内で読み取りコマンドを実行しました。監査ログにはコマンドのみが記録され、出力は記録されません。また一部のコマンドはエラーで失敗しているため、各データベースから実際にどれだけ読み取られたかは確認できません。当社はコマンドの内容から次のように判断しています。

PostgreSQLを使用するn8nのうち602個（確認した607個中）は暗号化キーを環境変数に記載していたため、n8n内のサードパーティの認証情報は平文で流出したのと同等です。今回のデータ読み取りはコンテナ内部で行われたため、8月のインシデント後に実施したデータベースのパスワード変更では、このアクセス経路を遮断できませんでした。

このほか、東京（hnd1）リージョンの少なくとも2つのPostgreSQLに、10月14日 01:51から外部へ接続を返すプログラムが仕込まれていました。そのうち1つは10月15日 16:24の時点でも外部への接続がありました。その侵入口が8月に流出したパスワードかどうかは、現時点で確認できない状態です。当社は発見時に、影響を受けたユーザーへ認証情報の差し替えを依頼しています。

GCPのDedicated Server。 調査の結果、攻撃者が101台のサーバーにroot権限でログインしていたことを確認しました。最後のログインは10月15日 20:36です。攻撃者はそのうち50台のサーバーに自身が管理するSSH公開鍵を追加し、継続的なアクセス経路を確保していました。また、ZeaburのGCPプロジェクト内に仮想マシンを5台作成し、16件の顧客サーバーのディスクのコピーをそれらの仮想マシンにマウントしていました。

このアクセス範囲を踏まえ、これら101台のサーバーはすべて、データ流出および不正アクセスの仕組みが残されている可能性がある影響対象ホストに分類しています。影響を受けたユーザーにはメールでお知らせし、該当サーバーのrootパスワードをリセットしました。

HetznerとDigitalOcean。 この2社のお客様のサーバーを管理するトークンは内部のコードと環境変数に記載されており、プラットフォームデータベースとともに流出しました。トークンを保持していれば、パスワードのリセット、OSの再インストール、ディスクの複製が可能です。当社は10月16日 01:09にすべてのトークンを失効させました。2社とも操作の監査ログがありません。Hetznerアカウントのイベントはすべてユーザーご本人またはシステムのスケジュールに対応しており、DigitalOceanは引き続き照合中です。

LinodeとTencent Cloud。 Linodeの890台のサーバーのうち、記録がある847台には攻撃者のログインはありませんでした。Tencent Cloudの管理用認証情報には、使用された記録はありません。

GitHub App。 攻撃者は10月15日 15:05にZeabur GitHub Appの秘密鍵を読み取りました。秘密鍵を保持していれば、ユーザーがZeaburにアクセスを許可したリポジトリにアクセスできます。当社は18:54に秘密鍵をローテーションしており、現時点で使用された形跡は見つかっていません。GitHub Supportに完全な監査ログを申請していますが、まだ回答を得ていません。

Zeaburの内部システム。 攻撃者はZeaburのAWSキーを複数使用しました。大部分のリクエストは拒否されましたが、攻撃者は2つのリージョンのユーザーのデータベースのバックアップと、ソースコードのアップロードの内容を一覧表示しました。ダウンロードしたかどうかは確認できない状態です。攻撃者はAmazon Bedrockの呼び出しを試みましたが、すべて失敗し、料金は発生していません。

当社の対応

完了した対応

当社はこのほか、コードにハードコードされていたTencent Cloud、Alibaba Cloud、Linodeの認証情報を無効化し、GCPサーバーから攻撃者のSSH鍵を削除し、各システムの監査ログを保全しました。

その後、以下の対応も完了しています。

• すべてのユーザーのプラットフォームのアクセストークンを失効。
• プラットフォームデータベースのアカウントのパスワードを含め、読み取られたその他の本番環境シークレットをローテーションし、流出したその他の認証情報を失効。
• GCPのDedicated Serverのユーザーにメールで通知し、サーバーのrootパスワードをリセット。
• プラットフォームデータベースに接続できるサービスを、指定したものに限定。
• クラスターのバックアップに平文のシークレットを保存しないようにし、バックアップのキーをその他のシークレットと分けて保管。
• 攻撃者が残したディスクの複製、スナップショット、テスト用リソースを削除。

進行中の対応

• 設定リポジトリ、古いGCPキー、9月初めのサーバーへのログインについて、流出元を調査。
• アラートの追加：管理権限の異常な使用、コンテナ内でのコマンド実行、シークレットやデータベースの大量読み取り、内部ネットワークへの新しいノードの参加、見慣れない送信元からのクラウドキーの使用。

サービスへの影響

お客様に必要な対応

通知メールを待たずに、今すぐ対応してください。8月のインシデント後に差し替えた認証情報も、もう一度差し替える必要があります。

すべてのユーザー

1. 環境変数内のすべての認証情報を差し替えてください。 APIキー、クラウドのキー、データベースのパスワード、署名キーと暗号化キーが含まれます。まずサービスプロバイダー側で古いものを失効させてから、新しいものを作成して再デプロイしてください。8月以降に環境変数をご自身のDedicated Serverに移行したプロジェクトでは、それらの変数は今回プラットフォームデータベースが読み取られた範囲に含まれません。ただしホスト自体が侵入された場合は、ホスト上に保存されている認証情報を差し替える必要があります。
2. 再ログインし、Access Tokenを作成し直してください。 古いプラットフォームのアクセストークンはすべて失効済みです。Access Tokenの管理ページで新しいトークンを作成し、心当たりのないリクエストがないか確認してください。
3. zSendをご利用の方： zSend APIキーを作成し直してください。
4. GitHubをご利用の方： GitHubの監査ログで、10月15日 15:05から18:54までのZeabur GitHub Appによる操作を確認してください。次の項目に注意してください。
   • 想定外のcloneやpush
   • 追加されたdeploy key
   • 変更されたwebhook
5. 請求を照合してください。 各サービスの2026年10月14日以降の利用量と請求を確認してください。GCPのDedicated Serverをご利用の方は9月1日まで遡ってください。10月14日は、当社が現時点で把握している、攻撃者が認証情報を使用した最も早い時刻であり、それ以前に認証情報が流出していなかったことを意味するものではありません。より早い時期の記録がある場合は、あわせて確認してください。

共有クラスターをご利用の方

1. データベース内でパスワードを変更してください。 Zeabur上の環境変数を変更するだけでは、データベース内のパスワードは変わりません。パスワードを変更しても、すでに流出したデータが無効になるわけではありません。データベースにお客様のユーザーのパスワードハッシュ、ログインセッション、トークンが保存されている場合は、あわせて失効させ、再生成してください。
2. n8n： n8nの暗号化キーを変更し、n8n内のすべてのサードパーティの認証情報を作成し直してください。
3. new-api／one-api： 上流のAIサービスのキーを失効させ、アクセストークンを再生成してください。
4. PostgreSQL： 心当たりのないロール、関数、トリガー、スケジュールジョブ、拡張機能がないか確認してください。懸念がある場合は、新しいデータベースを作成し、データのみをインポートしてください。
5. 台北（tpe1）と香港（hkg1）リージョン： データベースのバックアップ内のデータは流出したものとして扱ってください。

GCPのDedicated Serverをご利用の方

サーバーは侵入されたものとして扱ってください。

1. データをバックアップしたうえでサーバーを再構築してください。 これがバックドアを取り除く最も確実な方法です。
2. すぐに再構築できない場合は、少なくとも以下を行ってください。
   • /root/.ssh/authorized_keys から、コメントが @zeabur-pentest の鍵や心当たりのない鍵を削除する。
   • google-sudoers グループ、システムアカウント、crontab、systemdサービス、k3sのワークロードを確認する。
   • rootパスワードを変更し、SSHのパスワードログインを無効にする。
3. サーバー上のすべての認証情報を差し替えてください。 ご自身のクラウドの認証情報も含まれます。あわせて対応する請求を確認してください。
4. 侵害指標と照らし合わせてログイン記録を確認してください。 2026年9月1日まで遡ってください。

HetznerとDigitalOceanのDedicated Serverをご利用の方

コンソールで、10月14日以降にrootパスワードがリセットされていないか、OSが再インストールされていないかを確認し、上記のGCPの確認項目に沿って心当たりのないログイン手段がないことを確認してください。

発生の原因

発端： 攻撃者は、Zeaburのクラスター管理トークンと複数のクラウドのキーを保持していました。これらの認証情報は、設定リポジトリに平文で保存されていました。攻撃者がこれらをどのように取得したかは、現時点で確認できません。最も可能性の高い経路は未証明の推測をご覧ください。

影響範囲が拡大した関連要因：

• 管理トークンのライフサイクルとインターフェースのアクセス制御。 管理トークンには有効期限が設定されておらず、2024年1月の作成以来一度もローテーションされず、8月のインシデント後のローテーション対象にも含まれていませんでした。管理インターフェースはインターネットからアクセス可能でした。
• シークレットの保管と改善の進捗。 設定リポジトリ、コード、共有クラスターのサービス設定およびビルドジョブに、平文で保存されたキーが存在していました。GCPサーバーの初期化設定にもrootパスワードが保存されており、この問題は9月3日に特定されていましたが、インシデント発生前に修正は完了していませんでした。10月3日に開始したシークレット移行の変更は、インシデント発生時点でメインブランチにマージされていませんでした。
• バックアップの内容とキーの分離。 クラスターのバックアップにはすべてのシークレットが含まれ、バックアップのアクセスキーが他のシークレットと同じ環境に保管されていたため、バックアップ内容へのさらなるアクセス経路となりました。インシデント対応中にローテーションした一部の認証情報も、その後のバックアップに含まれていました。
• アクセス権限とリソースの範囲。
  • 単一のストレージの読み取りだけが必要なキーが、実際にはAWSアカウント内のすべてのストレージを読み取れる権限を持っていました。
  • GCPサーバーのデフォルトのサービスアカウントが、プロジェクトレベルの変更権限を持っていました。
  • 内部ネットワークのルールが、特定のタグを持つノードからプラットフォームデータベースへの接続を許可していました。
  • 内部の読み取り専用データベースアカウントが、すべてのデータを読み取れる権限を持っていました。
  • 停止済みサービスのデプロイキーが、サービス停止から4か月後も有効でした。
• 内部サービスとユーザーサービスの環境分離。 両者が同じクラスターにデプロイされていたため、攻撃者はユーザー設定を読み取る際に、内部サービスの認証情報も取得できました。
• 検知と監査ログの対象範囲。 10月14日に16時間以上続いた攻撃活動はアラートを発生させず、翌日ユーザーからの報告を受けてインシデントを特定しました。ストレージ、GCP、GitHubのアクセス記録が不完全なため、一部のアクセスと影響範囲は現在も確認できていません。

8月のインシデントとの関係

これは、Zeaburにとって2か月足らずのうちに起きた2件目のセキュリティインシデントです。8月以降、当社の案内に従って対応を行ったユーザーの方も多く、そうした対策を講じたのになぜまた起きたのか、2件のインシデントに関係はあるのか、という疑問をお持ちのことと思います。

8月以降に行ったこと。 当社は、当時流出が確認された内部キーをローテーションし、Legacy API Keyを廃止しました。プロダクト面では、Dedicated Serverのプロジェクトで環境変数と設定ファイルをご自身のサーバーに移行できるようにし、Zeaburが保持するSSH認証情報の削除と、SSHログイン記録の確認もできるようにしました。8月のインシデントの通知とお知らせでも、認証情報のローテーション、Zeaburに保存している環境変数と設定ファイルの削除、ご自身のサーバーへの移行をお勧めしていました。

それでも発生した理由。 8月のローテーションは、設定リポジトリに平文で保存されていたクラスター管理トークンとAWSキーを対象にしておらず、GCPサーバーの初期化設定内のrootパスワードもまだ修正されていませんでした。今回攻撃者が使用したのは、まさにこれらの認証情報です。8月のインシデントのレポートでは「すべての内部管理キーを無効化またはローテーションした」と記載していましたが、この記述は不完全であり、ここに訂正します。攻撃者がこれらの認証情報をどのように取得したかは、現時点で確認できません。当社の推測は未証明の推測をご覧ください。

効果があった点。 8月の案内に従って移行を完了したプロジェクトでは、環境変数と設定ファイルはお客様ご自身のサーバー上にのみ保存されており、今回プラットフォームデータベースから読み取られたデータには含まれていません。

時系列

攻撃者の活動と当社の対応

10月14日から15日にかけての、各システム上の攻撃者の活動と当社の対応（UTC）

攻撃者の操作

攻撃者がアクセス可能、連続した記録なし

当社の対応

調査開始

共有クラスターの管理インターフェース

ユーザーのデータベースコンテナ

AWSキーとシークレット

GCPのDedicated Server

内部ネットワークとプラットフォームデータベース

アカウントとサードパーティのキー

10/14

06:00

12:00

18:00

10/15

06:00

12:00

18:00

未解明の事項と調査の制約

以下の事項は、現存する記録の対象範囲または完全性の制約により、現時点では確認できていません。不正アクセスを排除できないデータと認証情報については、流出した可能性があるものとして対応しています。

• 初期の認証情報の入手経路。 現存するGitHubの監査ログはcloneを対象としておらず、アーカイブのダウンロードのみを記録しています。記録によると、8月30日と9月2日に従業員のGitHub認証を通じて設定リポジトリがダウンロードされていますが、実際の操作者はまだ確認できていません。GitHubに完全な記録の提供を依頼しています。現時点の見立ては未証明の推測をご覧ください。
• 共有クラスターのデータベースから実際に読み取られたデータの範囲。 監査ログには実行されたコマンドは残っていますが、出力内容は記録されていないため、実際に取得されたデータを完全には確認できません。
• バックアップとストレージオブジェクトのダウンロード範囲。 侵入されたホスト上の証拠から、攻撃者が10月15日 15:42に署名付きダウンロードURLを通じて顧客のデータベースバックアップを取得したことを確認しています。この証拠は、内部認証情報の流出に関与したと推定されるクラスターバックアップとは別のものです。後者がダウンロードされたかどうかは確認できていません。当時オブジェクトのアクセスログを有効にしていなかったため、その他のオブジェクトとクラスターバックアップの実際のダウンロード範囲は完全には確認できません。
• GCPリソースの読み取り範囲。 現存するGCPプロジェクトの記録は読み取り操作を対象としておらず、現時点で確認できるのは書き込み操作のみです。
• HetznerとDigitalOceanのトークンの使用状況。 両社とも本調査に利用できる操作の監査ログを提供していないため、これらのトークンが使用されたかどうかは確認できません。
• プラットフォームデータベースのクエリが返した具体的な内容。 攻撃者が実行したクエリと、そのうち主要な7件のクエリが返した件数は確認済みです。ただし、データベースのログは返された内容を記録しておらず、攻撃者がその後データをどのように保存・使用したかも確認できません。
• 一部クラスターの活動範囲。 台北（tpe0）クラスターと、攻撃者がリソースを作成した専用クラスターは監査ログが不完全であり、関連する活動の検証範囲が限られています。
• 10月14日以前の活動と影響。 現存する共有クラスターとAWSの記録には、10月14日 01:36より前に有効な認証情報が使用された活動は見当たりません。後に認証情報の不正使用に関与した一部のIPは、10月10日以降、未ログインのZeabur APIアクセス記録に現れています。ただし、これらのIPはプロキシサービスで共有されている可能性があり、IPが同じというだけでは操作者を特定できません。10月13日には専用サーバーへのSSHログインの試行もありましたが、すべて失敗しています。この期間にデータ流出があったかどうかは、現時点では確認できていません。

未証明の推測

以下は、当社が現時点で最も可能性が高いと考えている説明です。間接的な証拠に支えられていますが、直接の記録がないため、事実として引用することはできません。新たな証拠が得られた時点で、更新または撤回します。

1. 最初の認証情報は8月のインシデントに由来する可能性がある

• 推測： 攻撃者は、8月のインシデントで流出したGitHub Appの秘密鍵を利用して、Zeaburのプライベートな設定リポジトリの内容を取得した。その中には、10月14日に使用されたAWSキーとクラスター管理トークンが含まれていた。
• 現時点で、この経路を直接証明する証拠はありません。 以下は、時期と能力の面で一致する間接的な手がかりにすぎません。
• 差し替えたものと差し替えていないもの：
  • GitHub Appの秘密鍵：差し替え済み。 8月のインシデントで、この秘密鍵は8月27日に読み取られました。GitHubの監査ログとシークレット管理サービスのバージョンの時刻によると、秘密鍵は8月31日に差し替えられており、悪用可能だった期間は約4日間です。このAppはZeaburのGitHub organizationにインストールされており、秘密鍵を保持していればorganization内のすべてのリポジトリを読み取れます。
  • 設定リポジトリ内の平文の認証情報：差し替えていない。 10月14日に攻撃者が最初に使用したAWSキーとクラスター管理トークンは、8月27日の時点ですでに設定リポジトリに平文で存在していました。8月のインシデント後、当社は秘密鍵のみを差し替え、これらの認証情報は差し替えておらず、10月15日のインシデント対応で初めて無効化しました。したがって、秘密鍵が差し替えられた後でも、8月27日から31日の間に何者かがリポジトリの内容を取得していれば、その中の認証情報は10月の時点でも有効なままでした。
• その他の間接的な手がかり：
  • 攻撃者が読み取ろうとした内部シークレットの名前の一部は、別の内部リポジトリにのみ存在します。攻撃者は2つのリポジトリの内容を同時に保持していた可能性があり、これはAppの秘密鍵が持つorganizationレベルの権限と一致します。
  • 10月14日 01:36より前に、共有クラスターとAWSで有効な認証情報が使用された記録はなく、のちに認証情報を不正利用したIPもZeabur APIにログインしていません。これは「リポジトリ内の認証情報のみを保持していた」状況と一致します。
• 裏付けにならない手がかり： 8月のインシデントと今回のインシデントで、攻撃者のIPに重複はありません。
• 証拠収集の進捗： 当社はGitHub Supportに関連する記録を申請しています。8月27日から31日の間にこのAppが発行したアクセストークン、設定リポジトリのcloneとダウンロードの記録、8月30日と9月2日に従業員の認可で設定リポジトリをダウンロードした送信元が含まれます。本記事の更新時点で、まだ回答を得ていません。記録を入手するまで、この経路は推測にすぎません。従業員の認可によるダウンロードが別の取得経路であった可能性も否定できません。

2. 10月14日より前の探索は、同一攻撃者による偵察の可能性がある

• 推測： 10月10日から13日にかけての匿名の探索とSSHの試行は、同一の攻撃者が認証情報を使用する前に行った偵察である。
• 裏付けとなる証拠：
  • 103.237.102.191：10月10日 18:27に未ログインでZeaburを閲覧し、10月14日に管理トークンで共有クラスターにアクセス。
  • 23.106.46.239：10月12日 12:52から未ログインでZeabur APIへの試行を大量に行い、10月13日にDedicated ServerへのSSHログインを試行し、10月14日 01:36に流出したAWSキーを初めて使用。
• 未証明の点： 攻撃者はプロキシサーバーを大量に使用しており、同じIPが複数の人物に共用されている可能性があるため、IPが同じというだけでは同一人物と確認できません。

3. 10月15日のデプロイキーによるアクセスは攻撃者による可能性がある

• 推測： 10月15日 15:02、停止済みのサービスのデプロイキーが設定リポジトリを読み取った。これは攻撃者によるものと推定している。
• 裏付けとなる証拠： このアクセスは、攻撃者が本番環境シークレットを読み取っていた期間（14:52から16:51）に発生しています。キーが属するサービスは4か月前から停止しており、正常なアクセスはあり得ません。
• 未証明の点： 現時点で、このアクセスを攻撃者に直接結び付けられる記録はありません。

4. 流出したユーザーのキーがすでに不正利用された可能性がある

• 推測： 10月16日 01:50から02:56にかけて、1名のユーザーがZeaburに保存していたOpenAI APIキーが使用され、約1,107回の画像生成リクエストが送信された。当社は、このキーが今回流出した環境変数に由来すると推測している。
• 未証明の点： キーが別の経路で流出した可能性は否定できません。これは、本記事がすべてのユーザーにキーの差し替えをお勧めしている理由でもあります。お客様に必要な対応をご覧ください。

侵害指標

ご自身のシステムまたはサービスプロバイダーの記録で以下の指標が見つかった場合は、関連する認証情報を流出したものとして扱い、当社までご連絡ください。攻撃者はローテーションするプロキシサーバーを大量に使用しているため、下表には代表的なアドレスのみを記載しています。

用語の説明

• 共有クラスター（Shared Cluster）： 複数のユーザーのサービスがともに稼働するKubernetesクラスターです。当社は2026年2月に提供終了を告知しており、影響を受けたサービスはいずれも告知前にデプロイされたものです。
• Dedicated Server： Zeaburが管理し、単一のユーザーのサービスのみを実行するサーバーです。
• 管理トークン： クラスター全体を管理できる認証情報です。保持者はすべてのサービスの設定を読み取り、任意のコンテナ内でコマンドを実行できます。
• シークレット管理サービス： Zeaburが本番環境のシークレットを一元的に保管するために使用しているAWSのサービスです。
• 内部ネットワーク： Zeaburの本番環境のサービスを接続するプライベートネットワーク（Tailscale）です。プラットフォームデータベースはこのネットワークからの接続のみを受け付けます。
• プラットフォームデータベース： すべてのアカウント、プロジェクト、サービス、環境変数を保存しているZeaburの本番データベースです。

詳細情報

サポートが必要な場合、または異常なアクセスや心当たりのない料金を確認された場合は、Zeabur Support までご連絡ください。ご連絡の前に関連する認証情報を失効させ、マスキングした情報のみをお知らせください。有効なキーやパスワードを、サポートチケットや公開の場に記載しないでください。

本インシデントにより、サードパーティのAPIキーやクラウドアカウントで追加の料金が発生した場合は、サポートチケットより補償をお申し出ください。当社はサービスプロバイダーの利用記録と料金を確認し、確認結果をご説明します。

Zeaburは2026年12月31日をもってサービスを終了することを発表しています。これは経営上の判断です。それまでの間、本インシデントに関するサポートと補償の申請への対応を続け、本記事とステータスページの更新も継続します。影響を受けたすべてのユーザーの皆さまにお詫び申し上げます。

Zeaburチーム