Zeabur 2026年10月のセキュリティインシデントに関するご報告

本記事の時刻はすべて協定世界時（UTC）で表記しています。

2026年10月15日 13:56、当社はユーザーからの報告を受けて調査を開始しました。その後の記録の照合により、攻撃者は10月14日 01:36の時点ですでにZeaburの内部認証情報を使い始めており、当社が気付くより約36時間早かったことが判明しています。この間、攻撃者は有効な認証情報を使い、Zeaburの正規のアクセス経路を通っていたため、アラートは一度も発生しませんでした。

攻撃者は2つの経路から侵入し、10月15日にZeaburの内部ネットワークで合流して、プラットフォームデータベースを読み取りました。今回使われた認証情報は、8月のインシデント後に実施したローテーションの対象に含まれていませんでした。

お客様にお願いしたい対応

通知メールを待たずに、今すぐ対応してください。流出したデータは引き続き悪用される可能性があり、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の確認項目に沿って、心当たりのないログイン手段がないことを確認してください。

影響範囲

各システムの詳細は以下のとおりです。

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

10月15日 16:10から16:47にかけて、攻撃者は上表のデータを読み取りました。アカウントのデータには、メールアドレス、ユーザー名、電話番号など、プロフィールページ上の情報が含まれます。二要素認証とパスキーのテーブルについては統計情報が照会されたのみで、内容が読み取られた記録はありません。プラットフォームのアクセストークンはハッシュ値のみを保存していますが、当社はすべて失効させました。

攻撃者が主に探していたのは、そのまま使えるAPIキー、特にAIサービスのキーでした。環境変数と設定ファイルからAPIキーと秘密鍵を検索し、n8nとnew-api／one-apiの認証情報を大量に読み取り、ZeaburのAWSキーでAmazon Bedrockの呼び出しも試みています。これは、コマンドの内容とその後の行動から当社が読み取ったものです。攻撃者はアカウントのデータも読み取っており、当社は読み取られたすべてのデータを流出したものとして扱っています。

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

アカウントのなりすまし

10月15日 16:12から17:19にかけて、攻撃者は2つのアカウントになりすましてZeabur APIを呼び出し、アカウントとプロジェクトの一覧を読み取りました。そのうち1つはZeabur従業員のアカウントです。これらのリクエストで変更されたリソースはありません。

攻撃者はログイン用の認証情報を発行するためのキーを読み取っており、当社は、ログイン用の認証情報がこのキーで偽造されたと推定しています。プラットフォームのアクセストークンはハッシュ値のみが保存されており、攻撃者がそれを大量に読み取ったのも16:47になってからなので、16:12に始まったなりすましを説明できないためです。当社は20:25に署名キーをローテーションし、すべてのユーザーをログアウトさせました。

共有クラスターのデータベース

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

PostgreSQLを使用するn8nのうち、当社が確認した607個中602個は暗号化キーを環境変数に記載していたため、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、Linode、Tencent Cloud

HetznerとDigitalOceanのお客様のサーバーを管理するトークンは、内部のコードと環境変数に記載されており、プラットフォームデータベースとともに流出しました。トークンを保持していれば、パスワードのリセット、OSの再インストール、ディスクの複製が可能です。当社は10月16日 01:09にすべてのトークンを失効させました。2社とも操作の監査APIを提供していないため、トークンが使用されたかどうかは確認できません。除外できたのは、10月15日にHetzner上で行われたパスワードのリセットとイメージの作成が、お客様ご本人とシステムのスケジュールによるものだったという点のみです。DigitalOceanについては照合結果がありません。

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

GitHub App

10月15日 15:05、攻撃者はZeabur GitHub Appの秘密鍵を読み取りました。この秘密鍵を保持していれば、ユーザーがZeaburにアクセスを許可したリポジトリにアクセスできます。当社は18:54に秘密鍵をローテーションしました。秘密鍵が使用されたかどうかは確認できません。GitHub organizationの完全な監査ログを入手できておらず、GitHub Supportに申請した記録についても最後まで回答がありませんでした。

Zeaburの内部システム

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

サービスへの影響

経緯

攻撃者は2つの経路をたどりました。経路Aでは共有クラスターからZeaburのAWSとシークレット管理サービスに入り、経路BではGCPのDedicated Serverのroot権限を取得しています。10月15日、2つの経路はZeaburの内部ネットワークで合流しました。各段階に対応するMITRE ATT&CKのテクニックは付録をご覧ください。

インシデントの経路

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に保存されている環境変数、アカウント、プロジェクトのデータ

経路A：共有クラスターからシークレット管理サービスへ

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

経路B：GCPのDedicated Serverのroot権限

1. サーバーへのログイン。 10月14日 13:40から、攻撃者はZeaburがGCP上で管理するDedicated Server計101台にrootとしてログインしました。これらのサーバーの作成時、rootパスワードは初期化設定に平文で記載され、設定完了後も削除されていませんでした。プラットフォーム自体もこのパスワードでサーバーにログインする必要があったため、ハッシュ値ではなく平文で保存していました。攻撃者が保持していた古いGCPキーではこの設定を読み取ることができ、当社はパスワードがこの方法で入手されたと推定しています。
2. SSH鍵の追加。 10月15日 14:26から、攻撃者は古いGCPキーでサーバーの設定を変更し、自身のSSH鍵を追加しました。15:05には、シークレット管理サービスから本番環境のGCPキーをさらに1つ入手しています。
3. キーを替えて再試行。 当社が17:17に古いキーを無効化すると、11分後、攻撃者は新たに入手したキーに切り替えて再びSSH鍵を追加しました。当社は17:31にこのキーも無効化しました。

これらのログインは10月14日に発生しており、経路Aで本番環境シークレットが読み取られた最初の既知の記録（10月15日 14:52）より1日以上前です。そのため、経路Bの起点を経路Aで読み取られたシークレットで説明することはできません。同じ一群のサーバーには、9月1日から5日にかけても出所不明の送信元がrootパスワードでログインしており、9月5日当日は約98台でした。同一の攻撃者かどうかは確認できません。

2つの経路の合流

1. 内部ネットワークへの参加。 10月15日 15:30、攻撃者は侵入したGCPサーバーの1台で、経路Aで入手した内部ネットワークの管理用認証情報を使い、1つのノードをZeaburの内部ネットワークに参加させました。
2. プラットフォームデータベースの読み取り。 内部ネットワークのルールでは、この種のノードからプラットフォームデータベースへの接続が許可されていました。16:10から16:47にかけて、攻撃者は内部の読み取り専用アカウントでプラットフォームデータベースを読み取りました（確認済み）。
3. ノードの削除。 17:58、当社はこのノードを削除しました。

プラットフォームデータベースが読み取られたという結論は、内部ネットワーク両端の接続記録とデータベースのログに基づいています。この期間の29件のデータベース接続はすべてこのノードに対応しており、接続内のログインとクエリも一件ずつ追跡でき、操作記録は計8,903件でした。

検知

当社が調査を開始したのは、10月15日 13:56にユーザーからの報告を受けてからです。この時点で、攻撃者が最初に認証情報を使用してから（10月14日 01:36）約36時間が経過しており、10月14日の攻撃活動も16時間以上続いていました。

この間、アラートは一度も発生しませんでした。

• 攻撃者は有効な認証情報を使い、Zeaburの正規のアクセス経路を通っていたため、記録上は通常の管理操作と区別がつきませんでした。
• 当時は、管理権限の異常な使用、コンテナ内でのコマンド実行、シークレットの大量読み取り、内部ネットワークへの新しいノードの参加、見慣れない送信元からのクラウドキーの使用といった行動に対するアラートを設定していませんでした。

対応

封じ込め

調査開始から約4時間後に、攻撃者の内部ネットワークのノードを削除しました。10月15日から16日にかけての対応は以下のとおりです。

対応中に差し替えたキーの不正使用

インシデント対応の当日に差し替えた認証情報の一部は、その後も攻撃者に使用されました。原因はクラスターの日次バックアップです。日次バックアップはクラスター内のすべてのリソースを対象としており、シークレットも含まれていました。攻撃者は10月15日 15:04に、このバックアップのアクセスキーを読み取っていました。

1. 15:40、当社が新しいキーに差し替える。
2. 16:00、日次バックアップに新しいキーが含まれる。
3. 18:51、当社がバックアップのアクセスキーを削除する。
4. 20:30、攻撃者が新しいキーを使用する。
5. 21:47、当社が影響を受けた認証情報を再度ローテーションする。

新しいキーがバックアップに含まれたこと、その後に使用されたことは確認済みです。攻撃者がこのバックアップをダウンロードしたことは推定です。20:30に使われたキーは、攻撃者が18:51より前にすでに入手していたバックアップから得られた可能性もあります。

根絶と復旧

• GCPのDedicated Serverから攻撃者のSSH鍵を削除し、rootパスワードをリセットして、影響を受けたユーザーにメールでお知らせしました。
• 攻撃者が残したディスクの複製、スナップショット、テスト用リソースを削除しました。
• すべてのユーザーのプラットフォームのアクセストークンを失効させました。
• コードにハードコードされていたTencent Cloud、Alibaba Cloud、Linodeの認証情報を無効化しました。
• プラットフォームデータベースのアカウントのパスワードを含め、読み取られたその他の本番環境シークレットをローテーションし、流出したその他の認証情報を失効させました。
• 各システムの監査ログを保全しました。
• 影響を受けた機能はすべて復旧しています。各機能の影響期間はサービスへの影響をご覧ください。

根本原因

攻撃者は当初から、Zeaburのクラスター管理トークンと複数のクラウドのキーを保持していました。これらの認証情報はZeaburのプライベートな設定リポジトリに、従来からの運用のまま平文で保存されていました。最も可能性が高いのはこの設定リポジトリの流出ですが、流出経路は確認できません。当社の推測は未証明の推測をご覧ください。

攻撃者がプラットフォームデータベースに到達できた不備

• 管理トークンに有効期限がなく、管理インターフェースがインターネットに公開されていた。 トークンは2024年1月の作成以来一度もローテーションされておらず、8月のインシデント後のローテーションの対象にも含まれていませんでした。
• シークレットを平文で保存していた。 設定リポジトリ、コード、共有クラスターのサービス設定、ビルドジョブに、平文で保存されたキーがありました。GCPサーバーの初期化設定にrootパスワードが保存されている問題は9月3日に把握していましたが、インシデント発生までに修正していませんでした。10月3日に始めたシークレットの移行も、インシデント発生時点でメインブランチにマージされていませんでした。
• バックアップにすべてのシークレットが含まれ、バックアップのキーも他のシークレットと同じ場所に保管されていた。 そのため攻撃者はバックアップからさらに認証情報を入手でき、インシデント対応中に差し替えた認証情報の一部もその後のバックアップに含まれました。
• 権限が用途を超えていた。
  • 単一のストレージを読み取るだけでよいキーが、実際にはAWSアカウント内のすべてのストレージを読み取れました。
  • GCPサーバーのデフォルトのサービスアカウントが、プロジェクトレベルの変更権限を持っていました。
  • 内部ネットワークのルールは特定のタグを持つノードからプラットフォームデータベースへの接続を許可しており、内部ネットワークの管理用認証情報を使えば、新しいノードにそのタグをそのまま付けることができました。
  • 内部の読み取り専用データベースアカウントが、すべてのデータを読み取れました。
  • 停止済みサービスのデプロイキーが、サービス停止から4か月後も有効でした。
• 内部サービスとユーザーのサービスが同じクラスターにデプロイされていた。 攻撃者はユーザーの設定を読み取る際に、内部サービスの認証情報もあわせて入手しました。
• 検知と記録が不十分だった。 攻撃は約36時間続きましたが、アラートは一度も発生しませんでした。検知をご覧ください。ストレージ、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月の案内に従って移行を完了したプロジェクトでは、環境変数と設定ファイルがお客様ご自身のサーバー上にのみ保存されており、今回プラットフォームデータベースから読み取られたデータには含まれていませんでした。
• 調査開始から約4時間後に攻撃者の内部ネットワークのノードを削除し、同日中にクラスターの管理インターフェースとGCPのDedicated Serverへのインターネットからの接続も遮断しました。
• 内部ネットワーク両端の接続記録とデータベースのログが揃っていたため、プラットフォームデータベースの読み取り範囲を一件ずつ確認できました。

問題点

• 8月のインシデント後のローテーションは今回使用された認証情報を対象にしておらず、8月のインシデントのレポートの記述も不完全でした。8月のインシデントとの関係をご覧ください。
• GCPサーバーの初期化設定にrootパスワードが保存されている問題を9月3日に把握していながら、インシデント発生までに修正していませんでした。
• インシデント対応の当日に差し替えたキーが日次バックアップに含まれ、その一部がその後も使用されました。対応中に差し替えたキーの不正使用をご覧ください。
• 攻撃は約36時間続き、最終的にユーザーからの報告で発覚しました。検知をご覧ください。

改善策

Zeaburは2026年12月31日をもってサービスを終了するため、以下には実施済みの改善のみを記載しています。

未解明の事項

記録の制約により確認できない事項

以下の事項は、現存する記録の制約により、本記事の最終報告の時点でも解明できていません。アクセスされた可能性を排除できないデータと認証情報は、すべて流出したものとして扱っています。

• 最初の認証情報の入手元。 GitHubの監査ログにはアーカイブのダウンロードのみが記録されており、clone操作は記録されていません。記録によると、8月30日と9月2日に従業員のGitHubの認可を使って設定リポジトリがダウンロードされていますが、誰が行ったかは確認できません。GitHub Supportに完全な記録の提供を申請しましたが、最後まで回答はありませんでした。
• 古いGCPキーの流出元。 gitの履歴、シークレット管理サービス、旧クラスターのバックアップを調べましたが、流出元は見つかりませんでした。9月初めにrootパスワードでGCPのDedicated Serverにログインした 31.57.201.201 が同一の攻撃者かどうかも、結論は出ていません。
• 共有クラスターのデータベースから実際に読み取られたデータの量。 監査ログにはコマンドは残っていますが、出力は記録されていないため、当社が把握しているのは攻撃者が実行したコマンドのみです。
• バックアップとストレージオブジェクトのダウンロード範囲。 侵入されたホスト上の証拠から、攻撃者が10月15日 15:42に署名付きダウンロードURLを使って顧客のデータベースのバックアップを取得したことを確認しています。これは、内部認証情報を含むクラスターのバックアップとは別のものです。台北（tpe1）と香港（hkg1）のデータベースのバックアップ、およびソースコードのアップロード用ストレージについては、オブジェクトの一覧が表示されたことのみを確認しています。当時はオブジェクトのアクセスログを有効にしていなかったため、ダウンロードされたかどうかは確認できません。旧クラスターのバックアップが読み取られたかどうかについても直接の証拠はなく、推定のままです。
• GCPリソースの読み取り範囲。 当時GCPプロジェクトではデータアクセスの監査ログを有効にしておらず、書き込み操作の記録しかありません。事後に補完する手段もありませんでした。
• HetznerとDigitalOceanのトークンが使用されたかどうか。 両社とも操作の監査APIを提供していません。10月15日にHetzner上で行われた、お客様ご本人とシステムのスケジュールによるものと確認できた操作を除き、確認できません。
• GitHub Appの秘密鍵が使用されたかどうか。 GitHub organizationの完全な監査ログを入手できておらず、GitHub Supportからの回答もありません。
• プラットフォームデータベースのクエリが返した内容。 攻撃者が実行したクエリ、そのうち主要な7件のクエリが返した件数、そして14のコレクションがデータを返したことは確認済みで、主要なクエリはいずれも最後の1件まで読み取っていました。データベースのログは返された内容を記録しておらず、攻撃者がその後データをどのように保存・使用したかも把握できません。
• 一部のクラスターでの活動範囲。 台北（tpe0）クラスターと、攻撃者がリソースを作成した専用クラスターは監査ログが不完全であり、その後の追加調査も行っていません。
• 10月14日より前に何が起きていたか。 共有クラスターとAWSの記録には、10月14日 01:36より前に有効な認証情報が使われた活動はありません。のちに認証情報の不正利用に使われた一部のIPは、10月10日以降、未ログインのZeabur APIアクセス記録に現れています。ただし、これらのIPは複数人で共有されるプロキシサーバーである可能性があり、IPが同じというだけでは同一人物とは確認できません。10月13日にはDedicated Serverへの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か月前から停止しており、正常なアクセスはあり得ません。
• 証明できない理由： このアクセスを攻撃者に直接結び付けられる記録はありません。

付録

時系列

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

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

攻撃者の操作

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

当社の対応

調査開始

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

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

AWSキーとシークレット

GCPのDedicated Server

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

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

10/14

06:00

12:00

18:00

10/15

06:00

12:00

18:00

侵害指標

ご自身のシステムまたはサービスプロバイダーの記録で以下の指標が見つかった場合は、関連する認証情報を流出したものとして扱い、当社までご連絡ください。攻撃者はローテーションするプロキシサーバーを大量に使用しているため、下表には代表的なアドレスのみを記載しています。信頼度はSTIXの0から100の数値で、確認済みは85、推定は60、確認できないものは30としています。機械可読版はSTIX 2.1ファイルをご覧ください。ファイル内のIP指標の有効期限は2027年1月13日です。

MITRE ATT&CKとの対応

MITRE ATT&CK の戦術の順に記載しています。

用語の説明

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

サポートと費用

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

流出した認証情報が不正利用された場合、お客様に追加の費用が発生するおそれがあり、誠に申し訳ございません。現在の財務状況では、Zeaburは本インシデントに起因するサードパーティのサービス料金を負担することができません。多くのクラウドサービスやAPIサービスのプロバイダーには異議申し立てや減免の窓口があります。説明資料として、本報告書をプロバイダーに提出していただいて構いません。プロバイダーから他の証明を求められた場合は、サポートチケットでお知らせください。可能な限りご用意します。アカウント残高の返金は本インシデントの影響を受けません。詳しくは10月のセキュリティインシデントのその後の対応についてをご覧ください。

Zeaburは2026年12月31日をもってサービスを終了することを発表しています。これは経営上の判断です。それまでの間、本インシデントに関するサポートの申請には引き続き対応します。

攻撃者が認証情報を使い始めてから約36時間後に、当社はユーザーからの報告で初めて本インシデントを把握しました。お客様がZeaburに保存された認証情報を守ることは当社の責任であり、当社はその責任を果たせませんでした。影響を受けたすべてのお客様に多大なるご迷惑とご心配をおかけしましたことを、深くお詫び申し上げます。

Zeaburチーム