データ連携基盤のAirbyteを自社で運用している担当者は、Connector BuilderとManifest Serverの版・到達範囲・利用権限を優先して確認してください。2026年11月4日、JVNは任意コード実行の脆弱性を公表し、悪用確認済みとしています。データの取得・転送設定を扱うサービスで、コンテナ内のAirbyteユーザー権限でコードを実行される可能性があります。
JVNは「影響を受けるシステム」を修正し、開発元と同じ2.2.0未満という表記になりました。以前の列挙範囲だけで1.7.0より古い環境を対象外にした場合は、再点検してください。新しい別の脆弱性や修正版の発表ではありません。修正を含む最初の版は引き続き2.2.0です。
AIRBYTE_ENABLE_UNSAFE_CODEが無効でも、本件を防げたとは判断できません。Airbyte 2.xと旧Helm構成の1.xでは攻撃成立条件が異なります。修正は2.2.0ですが、更新前にDBバックアップと移行条件を確認してください。Self-Managed Enterpriseについては、2.2へ更新せず、Cloudプランへの移行を担当者へ相談するよう公式が案内しています。
今回扱う識別子はGHSA-g35w-6r6v-h4r7とJVN#12040144です。確認時点のAirbyte公式勧告は「No known CVE」と表示しています。CVE番号を推測で付けたり、別のAirbyte脆弱性の番号を流用したりしないでください。
初報と追報を分ける：11月10日は対象版表記の修正
| 日付 | 確認できること | 混同しないこと |
|---|---|---|
| 2026年8月10日 | 公式リリースノートに記載されたAirbyte 2.2の公開日 | 11月4日に初めて修正されたわけではない |
| 2026年10月17日 | 開発元がGitHub Security Advisoryを公表 | 脆弱性の発生・攻撃開始日とは限らない |
| 2026年11月4日12:00 JST | JVN新着一覧に本件を掲載。本文に悪用確認の記載 | 実悪用が最初に発生した日時や被害件数は未確認 |
| 2026年11月10日（JVN新着一覧は09:00 JST） | JVNが影響を受けるシステムを「Airbyte 2.2.0より前のバージョン」に修正 | 新しいCVEや追加修正版の発表ではない。初報時点から開発元は2.2.0未満と案内 |
日付の根拠はAirbyte 2.2リリースノート、前述の公式勧告、JVN本文の更新履歴、JVN新着一覧です。11月4日の初報には悪用確認の記載があり、11月10日の更新履歴は対象システムの修正を示しています。攻撃の開始日時や被害件数が新たに判明したという意味ではありません。
誰が対象か：Cloud、2.x、旧Helmの1.xを分ける
| 構成 | 開発元が説明する条件・対応 | 確認すること |
|---|---|---|
| Airbyte Cloud | 開発元は利用者側の対応不要と案内 | 契約先・運用形態が本当にAirbyte Cloudか |
| 自己管理の2.x、2.2.0未満 | Workspace ReaderまたはOrganization Reader以上の認証ユーザーから、Manifest Server内でコマンド実行のおそれ | Readerを含む権限付与と稼働版 |
| 旧Helm chartで配置した1.x | Connector Builderがglobal.auth.enabledを継承せず、サービスへのネットワーク到達だけで未認証の悪用が可能 | 管理画面の認証設定だけで対象外にしない |
| 1.x全般 | 開発元は1.x向け修正を提供しないと説明 | 修正版系列への移行計画。構成不明なら要確認扱い |
| Self-Managed Enterprise | 2.2への更新は行わず、Cloudプランへの移行をAirbyte担当者へ相談するよう公式が案内 | サポート担当と対応経路を合意する |
「クラウド上に置いている」だけではAirbyte Cloudとは限りません。自社のAWSやAzure、Google Cloudなどへ自分たちで構築したAirbyteは、自己管理の可能性があります。運用担当と更新責任を台帳で確認してください。
11月4日の本記事は、当時のJVNの列挙と開発元の「2.2.0未満」に表記差があることを説明し、広い範囲での棚卸しを勧めていました。11月10日現在、JVNも「Airbyte 2.2.0より前のバージョン」に修正され、この表記差は解消しています。古い資料を使って除外した資産がないかを確認し、自己管理環境は2.2.0未満を起点に、版別・構成別の条件を再点検してください。
再点検では、①以前「対象外」にした根拠と資料の日付、②現在稼働する本体版、③Connector Builder／Manifest Serverへの到達性、④版別の認証条件を残します。「対象版に含まれること」と「自社の構成で攻撃が成立すること」を同じ判定にせず、足りない情報を未確認として担当者へ戻してください。
なぜ「危険なコードを無効」にしていても問題になったのか
Connector Builderはデータ取得用コネクターを作る機能です。マニフェストは、その動きを指定する設定文書と考えると分かりやすいでしょう。本件では、設定から読み込めるPythonのクラス、つまり処理の部品の種類を十分に制限していませんでした。意図しない既存の部品を呼び出され、コンテナ内でのコード実行につながる問題です。
JVNはこれをCWE-470、安全ではないリフレクションとして説明しています。ここでのリフレクションとは、名前などを使って実行時に処理の部品を選ぶ仕組みです。便利な仕組みでも、外部から渡された名前をどこまで許すかが制限されていないと、設定データが実行機能へつながってしまいます。
2.2.0では、unsafe codeを明示的に有効化していない場合、Connector Builderから渡されるカスタムコンポーネントを拒否する修正が入っています。AIRBYTE_ENABLE_UNSAFE_CODE=trueは修正方法ではなく、意図的にカスタムコードを許可する設定です。確認のために有効へ切り替えないでください。
何が起こり得る？ コンテナと接続先の権限を確認する
開発元は、影響するコンテナから利用できるデータ・認証情報・秘密情報や、到達可能な内部サービスに影響が及ぶ可能性を挙げています。一方、全データベースの内容が必ず漏れる、ホストOSの管理者権限を必ず奪える、とまでは説明していません。実際の影響は、コンテナに渡している権限とネットワーク構成にも依存します。
運用上は、影響コンテナが参照できる接続情報と権限の範囲を確認します。DB、ストレージ、SaaSなどの名前を整理する際も、パスワードやトークンの値を一覧へコピーする必要はありません。権限の種類、利用先、保管場所の管理番号、変更責任者を記録すると、調査と必要な認証情報の更新を進めやすくなります。
| 発表元 | 評価方式 | 基本値 |
|---|---|---|
| Airbyte公式勧告 | CVSS 3.1 | 9.9（Critical） |
| JVN | CVSS 4.0 | 8.7 |
| JVN | CVSS 3.0 | 8.8 |
数値は発表元とCVSSの版を分けて記録してください。同じ尺度の値として平均したり、一つの点数に統一したりしません。運用の優先順位は、悪用確認、対象サービスへの到達性、利用権限、保持する情報も併せて判断します。
修正版を確認する：本体と同梱イメージの番号は別
| 項目 | 公式の修正情報 | 確認時の注意 |
|---|---|---|
| Airbyte本体 | 本件の修正を含む最初の版は2.2.0 | 2.2.0が現在の最新版という意味ではない。採用する版の更新経路も確認 |
| 同梱Manifest Server | 2.2.0はairbyte/manifest-server 7.23.7を同梱。CDKも7.23.7 | 本体2.2.0と部品7.23.7を同じ番号で比較しない |
| 1.x | 本件の修正提供なし | 同系列の更新だけで完了としない |
| 独自ビルド・ベンダー提供イメージ | 本記事だけでは修正包含を確定できない | 提供元の修正記録と実際のイメージを照合 |
社内ミラーやイメージ固定を使っている場合、更新したつもりでも古い部品が残ることがあります。マニフェストに書いた希望のタグと、実際に起動しているコンテナのイメージを分けて確認してください。手元のCLIの版や、更新コマンドの成功表示だけでは、稼働環境の修正確認になりません。
更新前の注意：DBの単純な巻き戻しはできない
公式の2.2リリースノートは、DB移行が2.1.xの必要とするテーブルを削除し、移行済みDBへ2.1.xのイメージを戻すロールバックをサポートしないと明記しています。更新前のバックアップが必要です。復元できること、復元時点以降の同期をどう扱うかも、担当者と確認してください。
同じリリースノートには、Helmのリソース設定の扱い、Community APIのHTTP Basic認証廃止、固定・ミラー運用時のmanifest-server 7.23.7の準備も記載されています。これらは更新後の起動・連携停止につながる条件です。安全性の修正と、業務が動き続けることの検証を両方用意します。
- 1運用形態・本体版・Helm chart・対象サービス・稼働イメージ・権限付与を読み取り専用で記録する。
- 2更新までの間に、下記の暫定策が必要か運用責任者が判断する。
- 3Self-Managed Enterpriseは2.2へ更新しない。Cloudプランへの移行についてAirbyte担当者へ相談するという公式案内に従い、対応方針を確認する。それ以外も採用する修正版の公式移行手順を確認する。
- 4DBバックアップと復元手順、同期停止・再開の段取り、イメージ入手、API認証方式を検証環境で確認する。
- 5承認済みの変更手順で更新し、対象コンテナの稼働イメージと本体版を再確認する。
- 6通常の接続・同期テストを行い、想定したジョブが成功すること、不要な公開や権限が残っていないことを確認する。
- 7脆弱性修正の完了と、過去の侵害調査の状況を別々に記録する。
この手順は運用上の推奨で、編集部がAirbyte実機を更新した記録ではありません。構成ごとの破壊的な更新コマンドを一律に提示せず、実環境の手順書と公式移行案内を照合してください。
すぐ更新できない場合の暫定策と限界
開発元の暫定策は、Connector Builder／Manifest Serverへ到達できる相手をAirbyte serverに制限することと、Workspace Reader・Organization Readerを信頼できる利用者に限定することです。実施する際は同期・テストなど正規機能への影響を確認します。
ただし、ネットワークを狭めたことだけで未修正の欠陥が消えるわけではありません。認証済みアカウントの悪用や、既存侵害も別問題です。誰が到達できるかと、誰がマニフェストを提出できるかを分けて点検してください。unsafe codeの無効化だけを本件の代替策としないことも重要です。
更新済みでも、過去の侵害確認は別に残す
悪用が確認されているため、未修正期間にサービスへ到達できた範囲と、アカウントの利用履歴を確認する価値があります。不審なテスト操作、コンテナの実行・再起動、権限変更、対象サービスからの外向き通信など、利用可能な記録を担当部門で照合してください。これらは調査項目の例で、本件固有の検出指標として実証したものではありません。
疑わしい兆候がある場合は、証拠を保全してインシデント対応へ引き継ぎます。秘密情報の更新や権限縮小は、露出範囲と業務影響を確認したうえで実施してください。ログがない場合は「侵害なし」ではなく「確認できない」と記録します。今回の一次資料から被害組織数や攻撃開始日は確認できていません。
LLMには秘密情報を渡さず、対象条件と未確認点を整理させる
対象はGHSA-g35w-6r6v-h4r7 / JVN#12040144です。提供する匿名化済み台帳と公式資料だけで、読み取り専用の棚卸しを補助してください。
入力：環境の仮ID、運用形態、本体版、Helm chart系統、稼働イメージ、対象サービスの到達範囲、ロールの種類、unsafe code設定の有無、バックアップ・更新・調査の状況。
パスワード、トークン、Secret原文、個人情報、ログ全文を要求しないでください。
1. Airbyte Cloudと自己管理環境を区別する。クラウド上に自社構築しただけではCloud扱いにしない。
2. 2.xのReader以上の認証条件と、旧Helmの1.xのネットワーク到達条件を分ける。
3. 2026年11月10日現在、JVNと開発元はともに2.2.0未満を対象としている。以前の列挙範囲だけで除外した資産は再点検し、古い1.xや不明な構成を安全と断定しない。
4. 本体2.2.0とmanifest-server 7.23.7を別項目にする。設定値と実稼働を混同しない。
5. Self-Managed Enterpriseは担当窓口への確認を残す。DB移行の単純なロールバックを提案しない。
6. unsafe code無効だけを安全の根拠にしない。CVE番号を創作しない。
7. 未実施・未確認はそのまま残す。修正完了と過去の侵害調査を別欄にする。
8. 更新、削除、権限変更、攻撃再現、外部スキャンを実行しない。
出力：仮ID / 対象判定の根拠 / 未確認点 / 暫定策案 / 更新前の確認 / 稼働確認 / 侵害調査 / 担当と期限。
LLMの回答をもって安全性の保証や対応完了としない。Airbyte対応記録シート（TXT）を用意しました。空欄を埋めるための教材で、サーバーへ接続したり自動判定したりするものではありません。基本的な対象判定は脆弱性ウォッチの初回も参照してください。
初回確認：2026年11月4日16時台JST。追報確認：2026年11月10日15時台JST。JVNの対象版表記の修正を、公式勧告・2.2リリースノートと再照合し、本文・LLM指示文・記録シートを更新しました。開発元の修正版2.2.0、1.x向け修正なし、Airbyte Cloudの利用者対応不要、Self-Managed Enterpriseの移行相談という案内は継続しています。実環境への接続、攻撃再現、Airbyte更新の実機試験は行っていません。追加の重要情報は本記事を更新します。