← 脆弱性の記事一覧へ

セキュリティノート

AirbyteConnector Builderの任意コード実行が悪用された

分類:攻撃手法認証回避攻撃手法RCE攻撃手法認証情報の悪用インシデント種別悪用確認

要点

影響を受けるもの

  • セルフホスト版Airbyte 2.2.0より前(Airbyteの勧告)。JVNは「1.7.0から2.1.0まで」と記載している(JVN#12040144、Airbyteの勧告 GHSA-g35w-6r6v-h4r7)。
  • Airbyte Cloudの利用者は対応不要(Airbyte)。

今すぐやること

  • セルフホスト版はAirbyte 2.2.0以降に更新する。1.x系には修正が出ないため、2.2.0以降への移行が必要。
  • すぐに更新できない場合は、Connector Builder/Manifest Serverに届く通信をAirbyteサーバーからだけに絞る。

何が起きているか

事実(Airbyte、JVN)

  • Airbyteは2026年10月17日に勧告を公開した。2.2.0より前のConnector BuilderとManifest Serverは、宣言型のマニフェスト(コネクタの定義ファイル)が「カスタムコンポーネント」として参照できるPythonのクラスを制限していなかった。マニフェストを送ってテスト読み込みができるユーザーは、コンテナ内にすでにあるPythonオブジェクトを読み込ませて呼び出し、Connector BuilderまたはManifest Serverのコンテナ内で任意のコマンドを実行できた(GHSA-g35w-6r6v-h4r7)。
  • カスタムコードを許可する設定 AIRBYTE_ENABLE_UNSAFE_CODE を有効にしていなくても成立した(Airbyte)。
  • 悪用に必要な条件は版によって異なる(Airbyte)。
    • 2.x(2.2.0より前):Workspace ReaderまたはOrganization Reader(閲覧権限)以上でログインしたユーザー。
    • 1.x(旧Helmチャートで構築):Connector Builderのサービスが global.auth.enabled の設定を引き継いでいなかったため、Connector Builderに通信が届く相手なら認証なしで悪用できた。
  • 悪用されると、コンテナから使えるデータ・認証情報・秘密情報が漏れ、コンテナから届く社内サービスにもアクセスされうる(Airbyte)。
  • JPCERT/CCとIPAは2026年11月4日、JVN#12040144を公開し、深刻度を「緊急」として「本脆弱性の悪用が確認されています」と記載した。弱点の分類はCWE-470(安全ではないリフレクション)。報告者は株式会社ZOZOの兵藤壮泰氏(JVN#12040144)。
  • 悪用した攻撃者、被害の件数、痕跡(IoC)は、AirbyteとJVNのどちらも公表していない。CVE番号は2026年11月7日時点でどちらの勧告にも書かれておらず、CISAのKEVにも登録されていない。

影響を受ける製品・バージョン

構成影響悪用の前提修正
Airbyte 2.x(2.2.0より前)影響あり閲覧権限以上のログイン2.2.0以降
Airbyte 1.x(旧Helmチャート)影響ありConnector Builderへのネットワーク到達のみ修正なし(2.2.0以降へ移行)
Airbyte Cloud対応不要――
  • 深刻度はAirbyteがCVSS 3.1で9.9(AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H)、JVNがCVSS 4.0で8.7、CVSS 3.0で8.8としている。

修正版・回避策

  • 修正:Airbyte 2.2.0以降に更新する。2.2.0には airbyte/manifest-server 7.23.7(airbyte-cdk 7.23.7)が含まれ、Connector Builderから送られたマニフェストのカスタムコンポーネントは AIRBYTE_ENABLE_UNSAFE_CODE=true でない限り拒否される(Airbyte)。
  • 回避策(Airbyte):
    • Connector Builder/Manifest Serverへのネットワークアクセスを、Airbyteサーバーからだけに限る。
    • Workspace Reader・Organization Readerの権限を信頼できるユーザーに限る。
  • Airbyteは、AIRBYTE_ENABLE_UNSAFE_CODE=true は意図的にカスタムコードを許す設定なので、ワークスペースの全ユーザーを信頼できる場合だけ有効にするよう注意している。

今すぐやること

  1. セルフホストのAirbyteの版を確認し、2.2.0より前なら更新する。1.x系は2.2.0以降への移行を計画する。
  2. 1.x系を旧Helmチャートで動かしている場合は、Connector Builderのサービスがクラスタ外や社内の広い範囲から届かないか、すぐに確認して遮断する。
  3. 閲覧権限を持つアカウントを棚卸しし、不要なものを外す。
  4. 更新前に信頼できない利用者やネットワークから届く状態だった場合は、Connector Builder/Manifest Serverのコンテナログを確認し、Airbyteに登録しているデータベース・API・DWHの接続用認証情報の交換を検討する。

考察

  • 「閲覧権限だけ」でも危ない: 2.xで悪用に必要なのは閲覧権限で、管理者である必要はない。社外の協力会社や分析担当者に閲覧権限を広く配っている組織ほど、影響を受けやすいと考える。
  • 狙われるのは連携先の認証情報: Airbyteは多くのデータベースやSaaSにつなぐための認証情報を持つ。コンテナ内でコマンドを実行されれば、Airbyte自体より連携先のデータが危ない。悪用が確認された以上、更新だけでなく認証情報の交換までを一連の対応と考えるべきだろう。
  • 安全設定がオフでも成立した点: AIRBYTE_ENABLE_UNSAFE_CODE を有効にしていないから大丈夫、と考えていた運用者は多いはずだ。安全側の設定が実際には効いていなかった種類の不具合なので、設定ではなく版番号で判断する必要がある。
  • 1.x系は修正が出ない: 旧Helmチャートの構成では認証すら不要だった。1.x系を使い続けている環境は、移行までの間、ネットワークでの遮断が唯一の守りになる。

出典

原文をGitHubで読む ↗

あわせて読む

シグナルトーク「Maru-Jan」 ― 不正アクセスで会員情報が流出