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

> 攻撃者が共有クラスターとGCPのDedicated Serverに侵入し、Zeaburのプラットフォームデータベースに保存されていた環境変数を読み取りました。本記事では、何が起きたのか、どのデータが影響を受けたのか、当社が行った対応、そしてお客様に必要な対応について説明します。

**本記事の時刻はすべて協定世界時（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に保存しているすべてのパスワードとキーを差し替えてください。手順は[お客様に必要な対応](#user-actions)をご覧ください。
- **根本原因：** 本インシデントの根本原因はZeaburにあります。長期間有効な管理用認証情報が平文で保存され、インターネットから使用できる状態でした。詳しくは[発生の原因](#root-causes)をご覧ください。
- **8月のインシデントとの関係：** 8月のローテーションは、今回使用された認証情報を対象にしていませんでした。一方、8月の案内に従って環境変数を移行したプロジェクトは、プラットフォームデータベースからの流出を免れました。詳しくは[8月のインシデントとの関係](#august-relation)をご覧ください。

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

<div id="what-happened" />

## 何が起きたのか

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

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

1. 10月14日 01:36から攻撃者はZeabur内部のAWSキーを、01:40から共有クラスターの管理トークンを使用しました。これらの認証情報は、Zeaburのプライベートな設定リポジトリに平文で保存されていました。攻撃者がこれらをどのように取得したかは、現時点で**確認できない**状態です。当社は、8月のインシデントで流出したGitHub Appの秘密鍵が関係していると推測しています。[未証明の推測](#hypotheses)をご覧ください。
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、当社はこのノードを削除しました。

<ConvergingChain
  title="インシデントの経路"
  description="2つの経路は内部ネットワークで合流しました。矢印の横は、各段階で攻撃者が利用した認証情報または不備です。"
  lanes={[
    {
      label: '経路A　共有クラスターとAWS',
      steps: [
        {
          zone: '起点',
          title: 'AWSキーとクラスター管理トークンを保持',
          detail: '取得方法は確認できない',
        },
        {
          via: '管理トークンに有効期限がなく、管理インターフェースがインターネットに公開',
          zone: '9つのリージョンの共有クラスター',
          title: 'すべてのサービスの環境変数、865個のデータベースコンテナ',
        },
        {
          via: '推定：権限過大なキーで旧クラスターのバックアップを読み取り',
          zone: 'AWS',
          title: 'シークレット管理サービスのキー',
        },
        {
          via: '確認済み：本番環境シークレットを読み取り',
          zone: 'Zeaburシークレット管理サービス',
          title: '約53件の本番環境シークレット',
          detail:
            '内部ネットワークの管理用認証情報とデータベースのアカウントを含む',
        },
      ],
    },
    {
      label: '経路B　GCPのDedicated Server',
      steps: [
        {
          zone: '起点',
          title: '古いGCPサービスアカウントキー1つ',
          detail: '流出元は確認できない',
        },
        {
          via: '推定：初期化設定内のrootパスワードを読み取り',
          zone: 'GCPのDedicated Server',
          title: '101台のサーバーのroot権限',
        },
      ],
    },
  ]}
  merge={{
    via: '侵入したサーバー上で、内部ネットワークの管理用認証情報を使ってノードを参加',
    zone: 'Zeabur内部ネットワーク',
    title: '本番環境の権限を持つノード1つ',
  }}
  after={[
    {
      via: '内部ネットワークのルールが接続を許可し、内部の読み取り専用アカウントでログイン',
      zone: 'Zeaburプラットフォームデータベース',
      title: 'Zeaburに保存されている環境変数、アカウント、プロジェクトのデータ',
    },
  ]}
  caption="図1：今回、攻撃者は経路Bで侵入したサーバー上で、経路Aで取得した内部ネットワークの認証情報を使ってノードを参加させました。ただし、お客様のサーバーへの侵入は、内部ネットワークへの参加に必須の条件ではありません。"
/>

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

<div id="what-information" />

## 影響を受けたデータ

| システム                                | 影響を受けたデータ                                                                           | 範囲                                               | 確度                                     |
| --------------------------------------- | -------------------------------------------------------------------------------------------- | -------------------------------------------------- | ---------------------------------------- |
| プラットフォームデータベース            | Zeaburに保存されているサービスの環境変数（名称と値）                                         | 3,218,965件                                        | 確認済み                                 |
| プラットフォームデータベース            | アカウント（メールアドレス、ユーザー名、電話番号など）、プロジェクト、環境、サービスのデータ | アカウント321,810件                                | 確認済み                                 |
| プラットフォームデータベース            | zSend APIキー（平文）                                                                        | 566個、失効済み                                    | 確認済み                                 |
| プラットフォームデータベース            | プラットフォームのアクセストークン                                                           | 11,536件。ハッシュ値のみで復元不可。すべて失効済み | 確認済み                                 |
| 共有クラスター                          | すべてのサービスの環境変数とシークレット                                                     | 9つのリージョン                                    | 一部確認済み、その他は確認できない       |
| 共有クラスター                          | データベースの内容                                                                           | 865個のデータベースサービス                        | 推定（下記の説明を参照）                 |
| GCPのDedicated Server                   | サーバー上のすべてのデータ                                                                   | 101台、92名のユーザー                              | ログインを確認済み                       |
| Hetzner、DigitalOceanのDedicated Server | サーバーの管理権限                                                                           | 359台と48台                                        | 使用されたかどうかは確認できない         |
| GitHub App                              | ユーザーが許可したGitHubリポジトリへのアクセス                                               | 10/15 15:05から18:54                               | 使用された形跡なし                       |
| ユーザーのデータベースのバックアップ    | 台北（tpe1）と香港（hkg1）リージョンのバックアップ                                           | 2つのリージョン                                    | ダウンロードされたかどうかは確認できない |

**プラットフォームデータベース。** 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              | 736 | サードパーティの認証情報、ユーザー、プロジェクト、変数、workflow     |
| PostgreSQL（テーブルごとに読み取り） | 211 | 各テーブル最大50,000件。台北（tpe1）リージョンは該当なし             |
| new-api／one-api                     |  10 | AIサービスのキー、アクセストークン、ユーザー                         |
| Redis                                |   1 | 名前にtoken、secretなどの文字列を含む項目                            |
| MongoDB、MariaDB                     | 各1 | 台北（tpe0）はコマンドの内容がないため、すべて流出したものとして扱う |

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の呼び出しを試みましたが、すべて失敗し、料金は発生していません。

<div id="what-we-did" />

## 当社の対応

### 完了した対応

| 時刻（10月15日） | 対応                                                                                                  |
| ---------------- | ----------------------------------------------------------------------------------------------------- |
| 14:43–15:56      | 共有クラスターの管理インターフェースへの接続をZeaburのシステムからのみに制限                          |
| 15:32            | 使用されたクラスター管理トークンを失効。21:47に再度ローテーション                                     |
| 17:17、17:31     | 攻撃者が使用した2つのGCPキーを無効化                                                                  |
| 17:58            | 攻撃者の内部ネットワークのノードを削除し、その作成に使われた認証情報を失効                            |
| 18:51            | クラスターのバックアップのアクセスキーを削除                                                          |
| 18:54            | GitHub Appの秘密鍵、決済サービスのキー、GitHub OAuthのシークレットをローテーション                    |
| 18:55            | GCPサーバーの初期化設定からrootパスワードを削除                                                       |
| 20:05–21:22      | 流出した、または流出を否定できない24組のAWSキーを無効化し、権限をより絞った新しいキーに差し替え       |
| 20:25            | ログイン署名キーをローテーションし、すべてのユーザーをログアウト                                      |
| 20:34–20:36      | GCPサーバーのデフォルトのサービスアカウントの権限を削除。GCPサーバーへのインターネットからのSSHを遮断 |
| 20:47            | 566個のzSend APIキーをすべて失効                                                                      |
| 21:46            | Zeaburが管理する専用クラスターへの接続をZeaburのシステムからのみに制限                                |
| 10/16 01:09      | 流出したHetznerとDigitalOceanのトークンを失効                                                         |

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

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

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

### 進行中の対応

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

### サービスへの影響

| 機能                                               | 影響期間（UTC）                                    | 現在の状況                                           |
| -------------------------------------------------- | -------------------------------------------------- | ---------------------------------------------------- |
| ログイン                                           | 10/15 20:25から再ログインが必要                    | 正常                                                 |
| zSendとシステムメール（ログインリンクを含む）      | 10/15 20:00–22:02                                  | 復旧済み。zSendのキーは再作成が必要                  |
| GitHubログインとデプロイ                           | 10/15 18:54–22:49                                  | 復旧済み                                             |
| ビルド                                             | 10/15 20:05–22:56。中国リージョンは10/16 01:44まで | 復旧済み                                             |
| データベースのバックアップ                         | 10/15 20:33–22:13                                  | 復旧済み                                             |
| GCPのDedicated Serverの管理                        | 10/15 17:31–20:35                                  | 復旧済み。WebのSSHのみ使用可能                       |
| Dedicated Serverの自動更新                         | Tencent Cloudで10/15 22:55–10/16 01:08に154回失敗  | 復旧済み。引き落とし分はアカウント残高として返金済み |
| Tencent Cloudのパスワードリセット、SSHログイン記録 | 10/15から                                          | 復旧済み                                             |
| LinodeのKubernetes専用クラスター                   | 10/15から                                          | 復旧済み                                             |

<div id="user-actions" />

## お客様に必要な対応

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

### すべてのユーザー

1. **環境変数内のすべての認証情報を差し替えてください。** APIキー、クラウドのキー、データベースのパスワード、署名キーと暗号化キーが含まれます。まずサービスプロバイダー側で古いものを失効させてから、新しいものを作成して再デプロイしてください。8月以降に環境変数をご自身のDedicated Serverに移行したプロジェクトでは、それらの変数は今回プラットフォームデータベースが読み取られた範囲に含まれません。ただしホスト自体が侵入された場合は、ホスト上に保存されている認証情報を差し替える必要があります。
2. **再ログインし、Access Tokenを作成し直してください。** 古いプラットフォームのアクセストークンはすべて失効済みです。[Access Tokenの管理ページ](https://zeabur.com/account/api-keys)で新しいトークンを作成し、心当たりのないリクエストがないか確認してください。
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. **[侵害指標](#indicators-of-compromise)と照らし合わせてログイン記録を確認してください。** 2026年9月1日まで遡ってください。

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

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

<div id="root-causes" />

## 発生の原因

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

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

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

<div id="august-relation" />

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

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

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

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

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

## 時系列

<ActivityTimeline
  legendLabels={{
    attacker: '攻撃者の操作',
    presence: '攻撃者がアクセス可能、連続した記録なし',
    response: '当社の対応',
  }}
  title="攻撃者の活動と当社の対応"
  description="10月14日から15日にかけての、各システム上の攻撃者の活動と当社の対応（UTC）"
  start="2026-10-14T00:00:00Z"
  end="2026-10-16T00:00:00Z"
  ticks={[
    { at: '2026-10-14T00:00:00Z', label: '10/14' },
    { at: '2026-10-14T06:00:00Z', label: '06:00' },
    { at: '2026-10-14T12:00:00Z', label: '12:00' },
    { at: '2026-10-14T18:00:00Z', label: '18:00' },
    { at: '2026-10-15T00:00:00Z', label: '10/15' },
    { at: '2026-10-15T06:00:00Z', label: '06:00' },
    { at: '2026-10-15T12:00:00Z', label: '12:00' },
    { at: '2026-10-15T18:00:00Z', label: '18:00' },
  ]}
  markers={[{ at: '2026-10-15T13:56:00Z', label: '調査開始' }]}
  lanes={[
    {
      label: '共有クラスターの管理インターフェース',
      spans: [
        { from: '2026-10-14T01:40:00Z', to: '2026-10-14T01:52:00Z' },
        { from: '2026-10-14T12:39:00Z', to: '2026-10-14T13:34:00Z' },
        { from: '2026-10-15T14:17:00Z', to: '2026-10-15T14:48:00Z' },
      ],
      responses: [
        {
          from: '2026-10-15T14:43:00Z',
          to: '2026-10-15T15:56:00Z',
          label: '管理インターフェースへの接続元を制限',
        },
        {
          from: '2026-10-15T21:46:00Z',
          to: '2026-10-15T21:48:00Z',
          label:
            '専用クラスターへの接続をZeaburのシステムからのみに制限。管理トークンを再度ローテーション',
        },
      ],
    },
    {
      label: 'ユーザーのデータベースコンテナ',
      spans: [{ from: '2026-10-14T13:40:00Z', to: '2026-10-14T17:04:00Z' }],
    },
    {
      label: 'AWSキーとシークレット',
      spans: [
        { from: '2026-10-14T01:36:00Z', to: '2026-10-14T01:50:00Z' },
        { from: '2026-10-14T14:47:00Z', to: '2026-10-14T17:53:00Z' },
        { from: '2026-10-15T14:36:00Z', to: '2026-10-15T17:04:00Z' },
        { from: '2026-10-15T19:06:00Z', to: '2026-10-15T19:11:00Z' },
        { from: '2026-10-15T19:57:00Z', to: '2026-10-15T20:04:00Z' },
        { from: '2026-10-15T20:30:00Z', to: '2026-10-15T20:34:00Z' },
        { from: '2026-10-15T21:05:00Z', to: '2026-10-15T21:06:00Z' },
      ],
      responses: [
        {
          from: '2026-10-15T18:51:00Z',
          to: '2026-10-15T18:52:00Z',
          label: 'クラスターのバックアップのアクセスキーを削除',
        },
        {
          from: '2026-10-15T20:05:00Z',
          to: '2026-10-15T21:22:00Z',
          label: '24組のAWSキーを無効化',
        },
      ],
    },
    {
      label: 'GCPのDedicated Server',
      spans: [
        { from: '2026-10-14T13:40:00Z', to: '2026-10-14T13:50:00Z' },
        {
          from: '2026-10-14T13:50:00Z',
          to: '2026-10-15T14:05:00Z',
          faint: true,
        },
        { from: '2026-10-15T14:05:00Z', to: '2026-10-15T17:42:00Z' },
        { from: '2026-10-15T19:50:00Z', to: '2026-10-15T20:53:00Z' },
      ],
      responses: [
        {
          from: '2026-10-15T17:17:00Z',
          to: '2026-10-15T17:18:00Z',
          label: '1つ目のGCPキーを無効化',
        },
        {
          from: '2026-10-15T17:31:00Z',
          to: '2026-10-15T17:32:00Z',
          label: '2つ目のGCPキーを無効化',
        },
        {
          from: '2026-10-15T18:55:00Z',
          to: '2026-10-15T18:56:00Z',
          label: '初期化設定からrootパスワードを削除',
        },
        {
          from: '2026-10-15T20:34:00Z',
          to: '2026-10-15T20:36:00Z',
          label:
            'デフォルトのサービスアカウントの権限を削除、インターネットからのSSHを遮断',
        },
      ],
    },
    {
      label: '内部ネットワークとプラットフォームデータベース',
      spans: [
        {
          from: '2026-10-15T15:30:00Z',
          to: '2026-10-15T17:58:00Z',
          faint: true,
        },
        { from: '2026-10-15T16:10:00Z', to: '2026-10-15T16:47:00Z' },
      ],
      responses: [
        {
          from: '2026-10-15T17:58:00Z',
          to: '2026-10-15T17:59:00Z',
          label: '攻撃者の内部ネットワークのノードを削除',
        },
      ],
    },
    {
      label: 'アカウントとサードパーティのキー',
      spans: [
        {
          from: '2026-10-15T16:12:00Z',
          to: '2026-10-15T17:19:00Z',
          label: 'アカウントになりすましてZeabur APIを呼び出し',
        },
      ],
      responses: [
        {
          from: '2026-10-15T18:54:00Z',
          to: '2026-10-15T18:55:00Z',
          label:
            'GitHub Appの秘密鍵、決済サービスのキー、GitHub OAuthのシークレットをローテーション',
        },
        {
          from: '2026-10-15T20:25:00Z',
          to: '2026-10-15T20:26:00Z',
          label:
            'ログイン署名キーをローテーションし、すべてのユーザーをログアウト',
        },
        {
          from: '2026-10-15T20:47:00Z',
          to: '2026-10-15T20:48:00Z',
          label: 'すべてのzSend APIキーを失効',
        },
      ],
    },
  ]}
  caption="図2：各システムの上段が攻撃者の活動、下段が当社の対応です。攻撃者は有効な認証情報とZeaburの正規のアクセス経路を使用しており、最初の既知の認証情報の使用（10/14 01:36）から調査開始までの約36時間、そのアクセスはアラートの対象になりませんでした。調査開始から約4時間後に、攻撃者の内部ネットワークのノードを削除しました。"
/>

| 時刻（UTC）     | 出来事                                                                                                       |
| --------------- | ------------------------------------------------------------------------------------------------------------ |
| 2024年1月10日   | 共有クラスターの管理トークンを作成。有効期限なし                                                             |
| 2026年1月20日   | 管理トークンが平文で設定リポジトリに書き込まれる                                                             |
| 8月27日         | 8月のインシデントで、GitHub Appの秘密鍵が読み取られる。本インシデントとの関連は推測                          |
| 8月30日、9月2日 | 設定リポジトリが従業員のGitHubの認可でアーカイブとしてダウンロードされる。ダウンロードした人物は確認できない |
| 8月31日         | GitHub Appの秘密鍵を差し替え。設定リポジトリ内の平文の認証情報はローテーションされず                         |
| 9月1–5日        | 出所不明の送信元が、約98台のGCPのDedicated Serverにrootパスワードでログイン                                  |
| 9月3日          | GCPサーバーの初期化設定にrootパスワードが保存されていることを把握。インシデント発生前に修正せず              |
| 10月10日 18:27  | のちに認証情報の不正利用に使われたIPが、Zeabur APIのアクセス記録に初めて出現（未ログイン）                   |
| 10月13日 21:27  | 攻撃者のIPが3台のDedicated ServerへのSSHログインを試行。23:04まで続き、すべて失敗                            |
| 10月14日 01:36  | 攻撃者がZeaburのAWSキーを初めて使用                                                                          |
| 10月14日 01:40  | 攻撃者が管理トークンで共有クラスターに初めてアクセス                                                         |
| 10月14日 12:39  | 攻撃者が共有クラスターのすべてのサービスの設定とシークレットを読み取り                                       |
| 10月14日 13:40  | 攻撃者がデータベースコンテナ内でデータの読み取りを開始。同時にGCPのDedicated Serverへのログインを開始        |
| 10月14日 17:04  | データベースコンテナ内での最後のコマンド                                                                     |
| 10月15日 13:56  | ユーザーからの報告を受け、調査を開始                                                                         |
| 10月15日 14:43  | 共有クラスターの管理インターフェースへの接続元の制限を開始                                                   |
| 10月15日 14:52  | 攻撃者が約53件の本番環境シークレットの読み取りを開始。16:51まで                                              |
| 10月15日 15:02  | 停止済みのサービスのデプロイキーが設定リポジトリを読み取り（攻撃者と推測）                                   |
| 10月15日 15:30  | 攻撃者が1つのノードをZeaburの内部ネットワークに参加させる                                                    |
| 10月15日 15:42  | 攻撃者がZeaburのストレージにあるユーザーのデータベースのバックアップをダウンロード                           |
| 10月15日 16:06  | 攻撃者が取得したデータからAPIキーを検索。18:13まで                                                           |
| 10月15日 16:10  | 攻撃者がプラットフォームデータベースの読み取りを開始。16:47まで                                              |
| 10月15日 16:12  | 攻撃者がアカウントになりすましてAPIの呼び出しを開始。17:19まで                                               |
| 10月15日 17:58  | 攻撃者の内部ネットワークのノードを削除                                                                       |
| 10月15日 19:50  | 攻撃者がGCPのDedicated Serverに2回目のログイン。20:36まで                                                    |
| 10月15日 20:25  | ログイン署名キーをローテーションし、すべてのユーザーをログアウト                                             |
| 10月15日 20:36  | GCPのDedicated ServerへのインターネットからのSSHを遮断し、攻撃者のログインが停止                             |
| 10月15日 20:48  | ステータスページを更新し、プラットフォームデータベースとDedicated Serverも影響を受けたと記載                 |
| 10月15日 21:01  | 攻撃者が共有クラスターのノードへのアクセスを試み、拒否される                                                 |
| 10月15日 21:05  | 現時点で観測されている攻撃者の最後の活動（AWS）                                                              |
| 10月16日 01:09  | HetznerとDigitalOceanのトークンを失効                                                                        |
| 10月16日 01:50  | 1名のユーザーのOpenAIキーが不正利用される。02:56まで（今回の流出によるものと推測）                           |

<div id="investigation-limits" />

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

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

- **初期の認証情報の入手経路。** 現存するGitHubの監査ログはcloneを対象としておらず、アーカイブのダウンロードのみを記録しています。記録によると、8月30日と9月2日に従業員のGitHub認証を通じて設定リポジトリがダウンロードされていますが、実際の操作者はまだ確認できていません。GitHubに完全な記録の提供を依頼しています。現時点の見立ては[未証明の推測](#hypotheses)をご覧ください。
- **共有クラスターのデータベースから実際に読み取られたデータの範囲。** 監査ログには実行されたコマンドは残っていますが、出力内容は記録されていないため、実際に取得されたデータを完全には確認できません。
- **バックアップとストレージオブジェクトのダウンロード範囲。** 侵入されたホスト上の証拠から、攻撃者が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ログインの試行もありましたが、すべて失敗しています。この期間にデータ流出があったかどうかは、現時点では確認できていません。

<div id="hypotheses" />

## 未証明の推測

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

**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回の画像生成リクエストが送信された。当社は、このキーが今回流出した環境変数に由来すると推測している。
- **未証明の点：** キーが別の経路で流出した可能性は否定できません。これは、本記事がすべてのユーザーにキーの差し替えをお勧めしている理由でもあります。[お客様に必要な対応](#user-actions)をご覧ください。

<div id="indicators-of-compromise" />

## 侵害指標

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

| 種類       | 指標                                                                                                 | 出現箇所                                                                                       |
| ---------- | ---------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- |
| IP         | `23.106.46.239`                                                                                      | クラスターへのアクセス、クラウドAPI、SSHログイン                                               |
| IP         | `102.244.78.57`                                                                                      | クラウドAPI、GCPの設定変更                                                                     |
| IP         | `103.237.102.191`                                                                                    | クラスターへのアクセス、クラウドAPI                                                            |
| IP         | `103.112.139.162`                                                                                    | クラスター管理トークンの最初の使用                                                             |
| IP         | `45.146.232.28`                                                                                      | AWSキーの検証                                                                                  |
| IP         | `216.98.11.198`、`45.58.38.175`                                                                      | Dedicated ServerへのSSHログイン                                                                |
| IP         | `52.220.72.188`                                                                                      | プログラムを仕込まれたPostgreSQLの接続先アドレス                                               |
| IP         | `31.57.201.201`                                                                                      | 9月初めにGCPのDedicated Serverへrootパスワードでログイン。本インシデントとの関連は確認できない |
| SSH鍵      | コメント `*@zeabur-pentest`、フィンガープリント `SHA256:EdBc0uephoOMemIRKK0SRV2TRR45n52tJm1yErVU1iM` | 攻撃者がDedicated Serverに追加した鍵                                                           |
| User-Agent | `Boto3/1.43.111`（Linux 6.12.86）                                                                    | 攻撃者がAWSキーの使用に用いたクライアント                                                      |

## 用語の説明

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

## 詳細情報

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

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

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

Zeaburチーム