kaniko 1.25.20 より前で Azure の認証トークンが紛らわしいホスト名のレジストリへ送られる CVE-2026-105769（CVSS v3.1 9.3）: Dockerfile の FROM 1 行で成立、1.25.20 で修正

NVD は 2026-11-02 に、コンテナイメージのビルドツール kaniko の脆弱性 CVE-2026-105769 を登録しました。kaniko は、Azure Container Registry（ACR）用の認証情報ヘルパーを使っています。このヘルパーは、ホスト名に .azurecr.io（ほかに .azurecr.cn・.azurecr.de・.azurecr.us）が含まれるだけで ACR のレジストリだと判断していました。判定が固定されていないため、x.azurecr.io.<別のドメイン> のような紛らわしいホスト名も通ってしまいます。その結果、ビルドが使う Azure の ID（Microsoft Entra ID）のアクセストークンが、そのホストへ送られるおそれがあります。

何が起きるか

• 種類（CWE-346・CWE-522）: 通信相手の確認が不十分なために、認証情報が保護されないまま外へ出る問題です。
• 成立する条件: 攻撃者が用意した Dockerfile（またはビルド引数）で、紛らわしいホストのイメージを FROM や COPY --from= に書くことです。RUN 命令やイメージの push は要りません。kaniko は、Docker の設定に認証情報がなく Google・Amazon のレジストリでもないホストについて、通信の前にこのヘルパーへ問い合わせます。ACR を使っていなくても対象になります。
• 前提となる環境: ビルドの環境で Azure の ID が取得できることです。具体的には、サービスプリンシパルの環境変数、フェデレーテッドなワークロード ID のトークン（AKS のワークロード ID など）、マネージド ID（Azure の VM や AKS ノードのメタデータサービス）のいずれかです。
• 影響: 相手のホストが、Azure Resource Manager 向けの有効なアクセストークンを受け取ります。有効期限が切れるまで、その ID に与えられたロールの範囲で Azure の操作に使えます。また、その ID が触れる ACR の認証情報に交換でき、push 権限があればイメージを書き込まれるおそれがあります。
• 評価: CVSS v3.1 は 9.3（CRITICAL、AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N）です。必要な権限はなし、ユーザーの操作は要（ビルドの実行）、スコープ変更ありです。NVD 自身の分析は未実施（Received）で、この値は CVE を登録した側（ベンダー勧告の公開元）によるものです。
• 影響範囲: kaniko 1.25.20 より前です。
• 攻撃の具体的な手順は、本記事では扱いません。

数値と出典（2026-11-03 時点）

項目	内容
CVE	CVE-2026-105769
CVSS v3.1	9.3（CRITICAL。種別 Secondary）
CWE	CWE-346、CWE-522
NVD の状態	Received（NVD 自身の分析は未実施）
NVD 公開日	2026-11-02
EPSS	未算定（FIRST の API に該当データなし）
KEV	掲載なし
修正版	1.25.20
出典	NVD、ベンダーのセキュリティ勧告（GHSA-5q7h-w9jf-cx97）、Go 脆弱性データベース（GO-2026-6225）

severity を critical とした提案の理由

認証なし（PR:N）で、ネットワーク越しに成立し、CVSS v3.1 が 9 以上（9.3）です。過去の判断の基準（認証不要かつ CVSS 9 以上は critical）に当てはまるため、critical を提案します。ただし、攻撃には「ビルドの環境に Azure の ID があること」と「信頼できない Dockerfile をビルドすること」が必要で、すべての利用者に当たるわけではありません。

対応として考えられること

1. kaniko の版を確認します。ベンダー勧告によると、リポジトリはバイナリやイメージを配布していないため、1.25.20 以降で executor・warmer・docker-credential-acr-env を作り直します。Go のモジュールとして取り込んでいる場合は、github.com/chainguard-dev/kaniko を 1.25.20 以降へ更新します。
2. すぐに更新できない場合は、信頼できないビルドから Azure の ID に届かないようにします。ビルド環境から Azure の資格情報・フェデレーテッドトークン・MSI_ENDPOINT・MSI_SECRET を外し、ビルドの Pod から 169.254.169.254（メタデータサービス）への通信を止めます（ベンダー勧告）。
3. kaniko 組み込みの ACR 認証を使っていなければ、kaniko のコンテナで AZURE_ENVIRONMENT に Azure のクラウド名ではない値（例: none）を設定すると、ヘルパーはトークンを要求する前に失敗します（ベンダー勧告）。
4. Docker の設定で "credsStore": "acr-env" を使っている場合は、自分の ACR 用のホストごとに credHelpers を設定する形へ替えます。これで塞がるのは単体のバイナリ経由の経路だけです（ベンダー勧告）。
5. 信頼できない Dockerfile を Azure の ID がある環境でビルドしたことがあれば、その間にその ID へ発行されたトークンは漏れた可能性があるものとして扱います。トークンは期限が切れるまで有効で、ID の資格情報を回しても取り消せません。Entra ID のサインインログと Azure のアクティビティログで、ACR への push・ロール割り当ての変更・キーやシークレットの一覧取得がないかを確認し、その ID が読めたシークレット（ストレージのキーなど）を更新します（ベンダー勧告）。

未確認の点

• 実際の攻撃での悪用は確認していません（CISA の SSVC の評価は exploitation: none ですが、公開直後の時点の評価です）。
• 製品の導入状況や、影響を受ける構成の件数は確認できていません。
• NVD の分析は未実施です。
• 修正版は 1.25.20 と記載されていますが、この版を取り込んだ配布物（各社のイメージなど）の状況は確認していません。