AirbyteのConnector Builderで悪用確認｜旧Helmの到達経路と更新前の注意点

データ連携基盤Airbyteの自社運用環境で、Connector Builderのテスト読み取りを通じて任意のコマンドを実行できる脆弱性について、JVNが2026年11月4日に悪用確認を公表しました。修正を含む最初の版は2.2.0です。運用担当者はプラットフォームの版に加え、Connector BuilderやManifest Serverへの到達経路、閲覧ロールの割り当て、実際のコンテナイメージを確認してください。すぐに更新できない場合は、先にサービスへの通信をAirbyteサーバーに限定します。

11月4日に分かったことと対象バージョン

JVNの脆弱性情報 JVN#12040144が示す影響範囲は1.7.0から2.1.0までです。Airbyteの公式勧告 GHSA-g35w-6r6v-h4r7では対象を「2.2.0未満」としています。両者で範囲の書き方が異なるため、JVNが挙げていない古い版を、範囲の差だけで対象外と判断しないでください。提供元は1.x向けに修正版を提供しないと案内しています。既にAirbyte Cloudを使う顧客は、提供元の勧告では対応不要です。

日付は三つに分かれます。2.2のリリースは8月10日、Airbyteの勧告公表は10月17日、JVNの初回公表は11月4日です。今回の新情報は、修正版が出たことではなく、JVNが悪用確認を明記したことです。JVNの公開資料には、悪用の発生日時や対象組織、被害規模は記載されていません。自社環境への侵入の有無は、稼働していた構成と記録を別途確認する必要があります。

Airbyteは深刻度をCritical、CVSS 3.1を9.9と評価しています。一方、JVNはCVSS 4.0で8.7、CVSS 3.0で8.8と公表しています。発行元と評価版が異なるため、この数値を一つの尺度の変動として読まないでください。Airbyteの勧告には既知のCVE番号が記載されていないため、本稿ではGHSA番号とJVN番号を識別子として使います。

1.xと2.xでは誰が攻撃できるかが違う

Connector Builderの宣言型マニフェストは、コネクターの動作を記述する設定です。修正前は、テスト読み取りに送られたマニフェストのカスタムコンポーネントが参照できるPythonクラスを十分に制限していませんでした。そのため、マニフェストの作成者が独自の実行ファイルを配布しなくても、コンテナに既にあるPythonオブジェクトをサービスに読み込ませ、意図しないコマンドを実行させることが可能でした。設定上は危険なコードを許可していなくても、修正前の版ではこの経路が残っていました。

2.2.0未満の2.xについて、提供元はWorkspace ReaderまたはOrganization Reader以上の認証済みユーザーを攻撃条件に挙げています。名称がReaderでも、脆弱な版ではテスト読み取りを通じてManifest Serverでコード実行に至り得ます。管理者だけを監査するのでは足りません。共同作業者や外部委託先など、閲覧目的で付与したロールについても、所属先とアクセスの必要性を調べます。

旧Helmチャートを使った1.xでは、Connector Builderサービスがglobal.auth.enabledの設定を引き継がず、サービスにネットワークで到達できるクライアントが認証なしに悪用できたとAirbyteは説明しています。確認するのは管理画面のログイン設定だけではありません。クラスタ内の別ワークロード、別名前空間、公開用プロキシなどから対象サービスへ直接届く経路がなかったかを確認します。インターネットに公開していなくても、内部から到達できる構成は切り分けの対象です。

コマンドが実行される場所は、影響を受けるConnector BuilderまたはManifest Serverのコンテナ内です。実行プロセスがアクセスできるデータや認証情報、接続可能な内部サービスに影響が及ぶ可能性があります。個々の環境で、何が読めるか、何を変更できるかは、マウント、実行権限、認証情報の配布先、ネットワーク構成によって変わります。コンテナ内での実行が直ちにホストの管理権限取得を意味するわけではありません。

今すぐ更新できない場合は到達経路から絞る

Airbyteが案内する暫定策は、Connector BuilderとManifest ServerへのネットワークアクセスをAirbyteサーバーだけに絞ることと、Workspace ReaderおよびOrganization Readerを信頼できる利用者に限ることです。二つは補完関係にあります。前者はサービスへの直接接続を減らしますが、正規のサーバーを経由した操作まで一律に止めるものではありません。後者だけでは、旧チャートでサービスに直接届く未認証経路を閉じられません。

Kubernetesで運用している場合、本サイトではまず稼働環境のService、IngressやGateway、既存のNetworkPolicyを照合することを勧めます。Helmの値だけでは、手動で追加した公開経路や、別の管理ツールが作ったルールまで分からない場合があります。ポリシーを使うなら、実際の名前空間とラベルでAirbyteサーバーを識別し、使用中のネットワーク実装がポリシーを適用することを確かめます。既存の許可ルールが対象への到達を残していないかも確認してください。

変更の確認には、Airbyteサーバーからの正規の通信と、対象外のワークロードからの通常の接続を分けて使います。前者では通常のコネクターテストが通り、後者では対象サービスに直接接続できないことを確認します。管理画面でテストが通ることだけをもって遮断成功としないでください。反対に、どこからも接続できない場合は、対策で本来必要な通信まで止めていないかを調べます。悪用コードを本番へ投入する必要はありません。

AIRBYTE_ENABLE_UNSAFE_CODEを有効にするのは回避策ではありません。提供元は、これを有効にするとマニフェストのカスタムコードを意図的に許可すると説明し、ワークスペースへアクセスできる全員を信頼できる場合に限るよう案内しています。既存のコネクターに独自コンポーネントがある場合は、更新前に一覧化し、利用者を絞った検証環境で代替手段を確認します。本番で動かなくなったコネクターを直すために、利用者の範囲を確認せず一律に有効化するのは避けてください。

Community版の更新とEnterprise版の判断を分ける

修正を含む2.2.0にはairbyte/manifest-server 7.23.7とAirbyte CDK 7.23.7が含まれます。更新後は、危険なコードの許可を明示的に有効にしない限り、Connector Builder経由のマニフェストでカスタムコンポーネントが拒否されます。プラットフォームの表示バージョンだけでは、イメージを固定した構成でManifest Serverも更新されたか分かりません。プライベートレジストリを使っている場合は、配布元、ミラー、実行中のイメージ参照を照らし合わせてください。

AirbyteのSelf-Managed 2.2リリースノートは、自社運用のEnterprise版を使い続けている場合はアップグレードせず、Cloudへの切り替えについてAirbyteの担当者へ相談するよう案内しています。一般のセキュリティ勧告にある修正版番号だけでEnterprise環境を更新しないでください。担当者と移行方法を確認する間は、到達制限とロールの点検を先行させ、現在の版、配備方法、必要な接続条件を伝えます。

Community版で2.2.0への更新を計画する場合、最初にデータベースのバックアップと復元手順を確認します。公式ノートによれば、2.2.0への移行は2.1.xが使うテーブルを削除します。移行済みDBのまま旧イメージだけに戻す方法はサポートされず、同期が止まります。復旧計画では、更新前に取得したバックアップをどの環境へ戻すか、復元した場合に更新後の変更や同期結果をどう扱うかを、作業前に決めておきます。大きなジョブテーブルがある場合はインデックス作成により起動工程が長引き得る点も、保守時間に織り込みます。

Community版のAPIを使うスクリプトには認証方式の変更もあります。2.2ではHTTP Basic認証が受け付けられなくなるため、curl -uなどで呼び出す運用スクリプトや監視を洗い出し、/api/v1/applications/tokenで得るアクセストークンへ切り替えます。更新後のAPIエラーが脆弱性修正による通信遮断とは限りません。認証方式、接続経路、APIの処理結果を分けて確かめると原因を切り分けやすくなります。

また、従来のglobal.jobs.resourcesと、レプリケーション用のglobal.workloads.resources.replication.*は更新前に見直します。前者は2.1.xのV2チャートで無視されていた値が2.2.0で一部の代替値として効くようになり、後者はレプリケーションのオーケストレーターの資源割り当てに影響します。更新後の同期が滞った場合は、認証やイメージ取得と並行して、展開されたCPU・メモリーの値も確認します。

更新確認と過去の悪用調査を別々に進める

更新後は、修正済みのイメージが実行されていること、不要な直接到達が遮断されていること、正規のAPIとコネクターテストが動くことを順に確かめます。同期の確認には、可能なら専用の接続と機密情報を含まない少量のデータを使います。検証環境では、必要に応じて危険な処理を含まない試験用カスタムコンポーネントが拒否されることも確認します。通常のテストが通った事実と、カスタムコンポーネントの制限が有効な事実は、別々の確認結果として記録します。

一方、更新に成功しても、更新前に発生したアクセスや認証情報の露出は取り消せません。影響を受ける版を稼働させていた期間と、サービスへの到達経路が存在した期間をまず整理します。その期間について、保存されていれば、プロキシやアプリのリクエスト記録、対象コンテナの実行記録、通信先のログを時刻で突き合わせます。旧チャートでは未認証で直接到達する経路が問題になるため、ログイン履歴だけで調査を終えないでください。テスト読み取りが記録されているだけでは悪用と判断できず、ログが存在しない期間について安全だったとも結論できません。

想定外の実行や通信が見つかった場合は、対象コンテナが当時読み取れた認証情報やデータを絞り込み、関連ログを保全し、調査担当へ引き継ぎます。失効や再発行が必要な認証情報については、同期元・同期先のどちらで使われていたか、交換後にどのジョブを再確認するかも決めます。修正の適用、暫定の通信制限、過去の影響調査は、それぞれ完了条件が異なります。運用記録も三つに分けておくと、更新が終わった後に調査が置き去りになるのを防げます。

関連記事

Webアプリのコンテナを非rootで動かすには？読み取り専用化と書き込み先の設計