Airbyteの脆弱性：Connector Builder経由のコード実行と2.2.0以降への更新手順

セルフホストのAirbyteで、2.2.0より前の版に任意コード実行の脆弱性が見つかりました。Connector BuilderとManifest Serverが、マニフェストに書かれたPythonクラスを制限なく読み込んでいたためです。GitHubのアドバイザリ（GHSA-g35w-6r6v-h4r7）はCVSS 9.9、2026年11月4日公開のJVNは「悪用が確認されています」と書いています。影響する構成の見分け方、版を確かめるコマンド、2.2.0以降へ上げる手順、更新までの緩和策を、2026年11月4日時点の公開情報で整理しました。

まとめ：セルフホストのAirbyteは2.2.0以降へ上げ、1.x系は移行を急ぐ

対応の本線は、Airbyteを2.2.0以降へ上げることです。2026年11月4日時点の最新は2.4.0で、修正は2.2.0から入っています。Airbyte Cloudの利用者は対応不要です。

急ぐべき環境は2つあります。1つは、レガシーHelmチャートで動かしている1.x系です。認証なしで悪用でき、1.x向けの修正は出ません。もう1つは、社外からログイン画面に届く2.x系です。読み取り専用の利用者でも攻撃の起点になります。

2.2.0への移行は戻せない一方向の更新なので、DBのバックアップを先に取ります。Airbyteのコンテナは、取り込み元と書き出し先の認証情報が集まる場所です。侵害の有無まで含めて点検したい場合は、脆弱性診断・セキュリティ診断で範囲を決めると漏れが出にくくなります。

GHSA-g35w-6r6v-h4r7：class_name経由の任意コード実行

GitHubのアドバイザリは2026年10月17日の公開で、CVE番号は付いていません。影響は2.2.0未満、修正版は2.2.0です。

カスタムコンポーネントの読み込み経路とPythonクラスの指定方法

AirbyteのConnector Builderは、画面上でAPIコネクタを組み、その場でテスト読み込みを試せる機能です。定義はYAMLの宣言的マニフェストで、2.x系ではManifest Serverというコンテナがそれを解釈して実行します。

マニフェストには、標準部品で足りない処理を自作のPythonクラスで補う「カスタムコンポーネント」を書けます。class_nameにクラスの完全修飾名を書くと、Manifest Serverがそれをimportして生成する仕組みです。公式ドキュメントはこの機能を「UNSAFE」かつ「EXPERIMENTAL」と位置づけ、サンドボックスは保証しないと明記しています。

問題は、class_nameに書けるクラスが制限されていなかったことです。コンテナの中に元からあるPythonのクラスや関数を指定すれば、意図しないオブジェクトを読み込ませてコマンドを実行できました。外部入力でクラスを選ばせる典型的な欠陥で、分類はCWE-470と、認証の欠如を指すCWE-306です。Airbyteの全体構成とConnector Builderの位置づけは、AirbyteのOSS版ELTの仕組みとセルフホスト構成で解説しています。

AIRBYTE_ENABLE_UNSAFE_CODEを無効にしていても防げなかった理由

Airbyteには、カスタムコードの実行を管理者が許可する環境変数AIRBYTE_ENABLE_UNSAFE_CODEがあり、既定は無効です。管理者の多くは「無効にしてあるから安全」と考えていたはずです。

実際には、この変数が止めていたのは、マニフェストに同梱するcomponents.pyのソースコードだけでした。class_nameでクラスを名指しする経路には効いていなかったのです。修正のPR #1076は2026年7月22日にマージされ、カスタムコンポーネントを生成する関数の先頭に判定を足しました。

判定はcustom_code_compiler.pyにあり、環境変数の値を小文字にしてtrueと比べるだけです。偽なら、クラスをimportする前にAirbyteCustomCodeNotPermittedErrorを送出します。公開済みのコネクタイメージに同梱されたマニフェストは信頼済みとして扱い、Connector Builderから送られたマニフェストだけを止める作りです。この修正はairbyte-cdk 7.23.7（2026年7月22日公開）に入り、同じ版番号のManifest Serverイメージが2.2.0の既定になりました。

GHSAとJVNで影響範囲・CVSS・悪用の記載が食い違う3点の読み方

2026年11月4日にJVN#12040144が公開されました。国内の報告者がIPAへ届け出て、JPCERT/CCが公表を調整した案件です。GHSAと突き合わせると、次の3点で記載が異なります。

CVSSの差は、影響が他のコンポーネントへ及ぶかを示すスコープ（S）の評価の違いから来ています。各指標の読み方はCVSSv3のスコアの目安と計算式で確認できます。

私たちは、影響範囲は広いGHSA側で判断します。2.1.1は2026年7月に出たパッチ版ですが、JVNの「2.1.0まで」という書き方を理由に対象外とは扱いません。悪用については、JVNの記載を前提に「狙われている」として優先度を上げます。

2024年のCVE-2024-38363と今回の任意コード実行の共通点

Connector Builderでの任意コード実行は、今回が初めてではありません。2024年7月のGHSA-4j3c-fgvx-xgqq（CVE-2024-38363）は、テンプレートの評価を悪用するSSTIで、0.62.2で修正されました。CVSS 3.1は8.5です。

2件に共通するのは、利用者が書いた定義をサーバー側で解釈して実行する機能だという点です。Connector Builderは、外部APIを試すための認証情報を入力する場所でもあります。私たちは、Connector Builderを「信頼できる人だけが触る、コード実行環境に準じる機能」として扱い、版の更新とは別に、誰が届くかを絞る運用を勧めています。

影響を受ける構成の見分け方：2.x系・1.x系レガシーHelm・Cloudの区別

同じAirbyteでも、動かし方によって攻撃の前提が変わります。

2.2.0未満の2.x系でReader権限の利用者が起点になる条件

2.x系では、ワークスペースかOrganizationのReader以上の権限を持つ、認証済みの利用者が攻撃の起点です。RBACの公式ドキュメントでは、Readerはワークスペースで最も弱いロールに当たります。Airbyteにログインできる人なら、ほぼ全員が条件を満たすと考えてください。

実行されるのはManifest Serverのコンテナの中です。GHSAは、コンテナから参照できるデータ・認証情報・シークレットの漏えいと、内部サービスへの到達を影響に挙げています。ログイン済みの利用者が、権限の境界を越えてAPIの裏側へ届く構図は、API不正アクセス対策の実装手順で扱った認可の欠陥と同じ型です。

レガシーHelmチャートの1.x系が認証なしで悪用される条件

1.x系をレガシーHelmチャート（chart V1）で動かしている場合、事情はさらに悪くなります。GHSAによると、Connector Builderのサービスがglobal.auth.enabledの設定を引き継がないためです。ネットワークで届く相手なら、ログインなしで悪用できます。

しかも、アドバイザリは1.x系に修正を出さないと明言しています。2.1.0からはchart V1自体のサポートも終わっています。1.x系のまま使い続ける選択肢は、事実上ありません。

abctl・helm・kubectlによる版と稼働イメージの確認コマンド

確認する対象は、Airbyte本体の版とManifest Serverの稼働イメージです。Airbyte本体の版は、Airbyteの画面の設定でも確かめられます。台数がある場合やイメージを固定している場合は、次のコマンドでまとめて確かめてください。abctlの環境は、名前空間がairbyte-abctl、kubeconfigが~/.airbyte/abctl/abctl.kubeconfigです（abctlの公式ドキュメント）。

# abctl で入れた環境：Helm チャートの版（Chart Version）とアプリの版（App Version）を表示
abctl local status

# Helm で入れた環境：APP VERSION 列が 2.2.0 以上なら修正版
helm list -n airbyte

# 実際に動いている Manifest Server のイメージを表示（7.23.7 以上なら修正入り）
kubectl -n airbyte get deploy \
  -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.template.spec.containers[0].image}{"\n"}{end}' \
  | grep -E "manifest-server|connector-builder"

# abctl の環境で kubectl を使うときは、次の2つを付ける
#   --kubeconfig ~/.airbyte/abctl/abctl.kubeconfig -n airbyte-abctl

上のコマンドは公式ドキュメントとHelmチャート2.4.0のテンプレートから書いたもので、私たちは未実行です。出力にconnector-builderを含むDeploymentが出てくる場合は、1.x系の構成と判断します。Helmチャートは2.2.0以降、チャートの版とアプリの版がそろっています（chart V2のドキュメント）。

2.2.0以降へ上げる手順：一方向のDB移行とイメージ固定の落とし穴

修正版へ上げる作業そのものは短いものの、2.2.0には戻れない変更が含まれます。

2.2.0のDB移行が一方向になるため更新前に取るバックアップ

2.2のリリースノート（2026年8月10日）は、この更新を「one-way」と書いています。2.2.0のマイグレーションは2.1.x系が使うテーブルを削除するため、2.1.x系のイメージへ戻すことはできません。

更新の前に、AirbyteのDBをバックアップします。外部のPostgreSQLを使っているなら、マネージドDBのスナップショットで構いません。同梱のPostgreSQLなら、Podの中でpg_dumpを取ってから進めます。同じリリースノートは、大きなjobsテーブルではインデックスの作成で起動に時間がかかることにも触れています。メンテナンスの時間は長めに取ってください。

2.2では、コミュニティ版のAPIがHTTPのBasic認証を受け付けなくなりました。curl -uでAPIを呼ぶスクリプトがあるなら、アクセストークンを使う形に直してから上げます。

abctlとHelmそれぞれの更新コマンドとチャート版の固定

公式のアップグレード手順に沿うと、コマンドは次のとおりです。abctlの環境では、先にabctl自体を0.30.0以降にしておく必要があります。

# abctl の環境：版を指定して入れ直す（指定しなければ最新版）
abctl version
abctl local install --chart-version 2.4.0

# Helm の環境：リポジトリ名は helm repo add したときの名前に合わせる
helm repo update
helm upgrade airbyte airbyte/airbyte \
  --namespace airbyte \
  --values ./values.yaml \
  --version 2.4.0

私たちは、2.2.0で止めずに2.4.0まで上げることを勧めます。2.4には、1つのリクエストが別のワークスペースのリソースを参照する問題（CVE-2026-80049）の修正も入っているためです。

ただし2.3を越える場合、同梱のMinIOを使う環境では手作業が1つ増えます。MinIOのイメージの取得元がairbyte/minioに変わり、StatefulSetのイメージ変更とPodの削除が要るためです。外部のS3やGCSを使っている環境では不要です。helm upgradeの基本はHelmの主要コマンドで整理しています。

イメージをミラー・固定している環境で更新後も修正が入らない落とし穴

見落としやすいのはここです。修正の本体は、AirbyteのサーバーではなくManifest Serverのイメージの側にあります。

values.yamlでmanifestServer.image.tagを古い版に固定していると、チャートを2.4.0へ上げても、Manifest Serverは修正前のまま動き続けます。社内レジストリにミラーしている環境では、新しいタグが無いとPodが起動しません。チャートの既定は、2.2が7.23.7、2.3以降が7.28.2です。

更新が終わったら、前の章のkubectlのコマンドでManifest Serverのイメージを必ず見直してください。7.23.7より前の版が出たら、版を固定している設定を探して外します。

更新後にカスタムコンポーネントを無効のまま維持できているか確かめる手順

修正後は、AIRBYTE_ENABLE_UNSAFE_CODEがtrueでない限り、Connector Builderから送られたカスタムコンポーネントは拒否されます。逆に、この変数をtrueにしている環境では、修正版に上げても今回の攻撃が成立する余地が残ります。

# Manifest Server の Deployment に AIRBYTE_ENABLE_UNSAFE_CODE が設定されているかを見る
# （Deployment 名は「Helm のリリース名-manifest-server」。abctl では airbyte-abctl-manifest-server）
kubectl -n airbyte get deploy airbyte-manifest-server \
  -o jsonpath='{.spec.template.spec.containers[0].env[?(@.name=="AIRBYTE_ENABLE_UNSAFE_CODE")].value}'
# 何も表示されなければ未設定（無効）。true と出たら values.yaml の extraEnv を見直す

このコマンドも未実行です。カスタムコンポーネントの公式手順では、この変数をworkloadLauncherとmanifestServerのextraEnvで渡します。過去に有効化した手順書があるなら、その行が残っていないかも確かめてください。

更新までの緩和策と、Airbyteへ届く人を絞る運用の判断基準

すぐに上げられない場合に、攻撃の入口を狭める方法です。GHSAが挙げる回避策は2つあります。

Manifest Serverへの通信元を制限するNetworkPolicy設定

1つ目は、Connector BuilderとManifest Serverへの通信を、Airbyteのサーバーからだけに限ることです。Helmチャート2.4.0のテンプレートでは、Manifest ServerのPodにapp.kubernetes.io/name: manifest-server、サーバーのPodにapp.kubernetes.io/name: serverのラベルが付き、待ち受けは8080番です。

# manifest-server-netpol.yaml：Manifest Server への接続を airbyte-server の Pod からだけ許可する
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: manifest-server-allow-server-only
  namespace: airbyte
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: manifest-server
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app.kubernetes.io/name: server
      ports:
        - protocol: TCP
          port: 8080

適用はkubectl apply -f manifest-server-netpol.yamlです。この定義はチャートのテンプレートから書いたもので、私たちは未実行です。Kubernetesの公式ドキュメントのとおり、NetworkPolicyはCNIが対応していないと効きません。適用前にkubectl get pods --show-labelsで実際のラベルを確かめ、適用後はConnector Builderのテスト読み込みが通ることを見ます。CNIの選び方はCiliumとCalicoの比較で扱っています。

この緩和策で止まるのは、Manifest Serverへ直接届く経路だけです。2.x系では、正規にログインした利用者がサーバー経由で送るマニフェストは止められません。だから、2つ目の対策と組み合わせます。

Reader権限の棚卸しとカスタムコード実行を許可する環境の判断基準

2つ目は、Workspace ReaderとOrganization Readerの権限を、信頼できる人だけに絞ることです。カスタムコードの実行許可の判断対象は、AIRBYTE_ENABLE_UNSAFE_CODEをtrueにするかどうかという設定です。退職者や外部の協力会社のアカウント、検証のために作った共有アカウントが残っていないかを確かめます。ロールの設計の考え方は、RBACの仕組みと実装手順で整理しています。

GHSAは、AIRBYTE_ENABLE_UNSAFE_CODE=trueを、ワークスペースに届く全員が信頼できる場合に限るよう求めています。私たちの判断はこうです。カスタムコンポーネントが要るコネクタは、Connector Builderで本番環境に直接書かず、コネクタのイメージとして作って配る形に寄せます。この変数をtrueにするのは、利用者が開発者数名に限られる検証用の環境だけです。

ログイン画面をインターネットから直接開ける構成は、今回の更新を機にやめます。VPNか、IdP連携の認証プロキシの内側へ移してください。社内からしか届かず、使う人が運用担当の数名に限られるなら、公開範囲はそのままで更新の速さを優先して構いません。

侵害を疑うときに見直すコネクタの認証情報とローテーションの順番

JVNが悪用を確認している以上、未修正の期間に社外から届く状態だった環境は、侵害の可能性を前提に点検します。Manifest Serverのコンテナから参照できた認証情報とシークレットは、漏れたものとして扱います。

入れ替えの順番は、書き込み権限を持つものから進めます。最初は、書き出し先のデータウェアハウスやDBの認証情報です。次に、取り込み元のSaaSのAPIキーとOAuthのトークン、最後にAirbyte自体の管理者のパスワードとアクセストークンです。KubernetesのSecretに置いた値も、同じ順で入れ替えます。

あわせて、Airbyteの監査に使えるログと、書き出し先のDBに想定外の接続元からのログインが無いかを確かめます。Airbyteのような取り込み基盤は、ETLの経路全体の認証情報が1か所に集まる場所です。構成の全体像はETLの仕組みとELTとの違いで確認できます。点検の範囲を自社だけで決めにくい場合は、脆弱性診断の種類と外注時の判断基準で進め方を確かめてください。

Airbyteの脆弱性と2.2.0以降への更新でよく受ける質問と回答

今回の対応を進める中で出てきやすい疑問に、公開されている一次情報の範囲で答えます。

Airbyte Cloudを使っている場合も対応は必要ですか？

GHSAは、Airbyte Cloudの利用者は対応不要としています。修正はAirbyte側の環境に適用済みという扱いです。ただし、Cloudと並行してセルフホストの検証環境やConnector Builder用の環境を立てているなら、そちらは対象です。社内に眠っているabctlの環境が無いかを、念のため確かめてください。

2.1.1を使っていますが、影響を受けますか？

受けるものとして扱ってください。JVNは影響範囲を「1.7.0から2.1.0」と書いていますが、GHSAは「2.2.0未満」としています。修正のPRがマージされたのは2026年7月22日で、2.1.1が出た後です。2.1.1に修正は入っていないため、2.2.0以降への更新が必要です。

CVE番号が無いと、脆弱性の管理ツールで検出されませんか？

検出されない場合があります。2026年11月4日時点で、GHSAにもJVNにもCVE番号の記載はありません。CVE番号で照合する仕組みでは、今回の件が一覧に出てこない可能性があります。GHSAのID（GHSA-g35w-6r6v-h4r7）とJVNの番号（JVN#12040144）で、台帳に手で登録しておくと追跡が漏れません。

2.2.0以降に上げると、自作のコネクタは動かなくなりますか？

Connector Builderから送るマニフェストのうち、カスタムコンポーネントを使うものは、AIRBYTE_ENABLE_UNSAFE_CODEがtrueでない限り拒否されます。標準部品だけで組んだマニフェストは影響を受けません。CDKの現行のコードでは、公開済みのコネクタイメージに同梱されたカスタムコンポーネントは、この変数が無くても動く扱いです。更新前に、自作のコネクタがclass_nameを使っているかを確かめてください。

1.x系のまま当面使い続ける場合の最低限の対策は何ですか？

1.x系への修正は出ないため、移行までの時間稼ぎとして考えます。Connector Builderのサービスへの通信をAirbyteのサーバーからだけに限り、社外から届かないネットワークへ置くことが最低限です。認証なしで悪用できる構成なので、ログイン画面の前に認証プロキシを置くだけでは足りません。2.1.0以降はchart V1のサポートも終わっています。新しい名前空間にchart V2で立て直す計画を、今回の対応と並行して進めてください。

関連記事

• Airbyteとは？OSS版ELTの仕組み・セルフホスト構成とFivetranとの違いを実装視点で解説【2026年版】：今回の脆弱性の前提になる、Airbyteの構成とchart V2への移行です。
• API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効とアプリ解析・SSRF対策：ログイン済みの利用者に権限の境界を越えさせない認可の実装です。
• Helmとは？helm repo addの使い方と主要コマンド【Helm 4.3対応】：2.2.0以降へ上げるときに使うhelm upgradeの基本です。
• RBAC（ロールベースアクセス制御）とは？仕組みと実装手順をSQL・Kubernetesの例で解説：Reader権限を棚卸しするときのロール設計の考え方です。
• Ciliumとは？eBPFベースのKubernetes CNIの仕組みとCalico比較・導入判断を解説：NetworkPolicyによる緩和策を効かせるCNIの選び方です。