CVE-2026-32193は、Azure Kubernetes Service（AKS）に存在するパストラバーサルの脆弱性です。悪用されると、認可済みの攻撃者にローカルでコードを実行される可能性があります。
AKS管理者が最初に行うべきことは、Kubernetesバージョンを闇雲に更新することではありません。Azure Service Healthの通知、AKSリリース、ノードイメージ、自動更新設定を確認し、Microsoftが示す修正対象と自分のクラスターを照合することが重要です。
特に注意したいのは、影響バージョンとして示されているv0.20260213.5が、通常のKubernetesバージョンやノードイメージ番号とは異なる点です。この値だけを見て、Kubernetesのマイナーバージョン更新やノード再作成を判断してはいけません。
CVE-2026-32193の概要
CVE-2026-32193は、2026年6月9日にMicrosoftから公開されたAzure Kubernetes Serviceのコード実行脆弱性です。2026年6月17日には、影響を受けるバージョンとしてv0.20260213.5未満という情報が追加されています。(Microsoft Security Response Center)
| 項目 | 内容 |
|---|---|
| 対象サービス | Azure Kubernetes Service |
| 脆弱性の種類 | パストラバーサル |
| CWE | CWE-22 |
| 想定される影響 | 認可済み攻撃者によるローカルでのコード実行 |
| CVSS 3.1 | 8.8／High |
| 攻撃元区分 | Local |
| 必要権限 | Low |
| ユーザー操作 | 不要 |
| 影響バージョン | v0.20260213.5未満として登録 |
| 公開日 | 2026年6月9日 |
CVSSベクターはAV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:Hです。攻撃の複雑さは低く、ユーザー操作を必要とせず、成功した場合は機密性・完全性・可用性のすべてに大きな影響が及ぶと評価されています。(NVD)
「RCE」でもインターネットから直接攻撃されるとは限らない
MSRCではRemote Code Execution Vulnerabilityとして扱われていますが、公開されているCVSSのAttack VectorはLocalです。また、説明では「authorized attacker」、つまり認可済みの攻撃者がコードを実行できるとされています。
したがって、公開情報だけを見る限り、インターネット上の第三者が認証なしでAKSクラスターへ直接侵入できる脆弱性とは読み取れません。攻撃には、低権限であっても何らかの認可済み実行経路や、クラスター内の足場が必要と考えるのが妥当です。
ただし、次のような環境では、足場を取得される可能性や被害範囲が大きくなるため、優先度を上げる必要があります。
| 優先度 | クラスターの状況 |
|---|---|
| 最優先 | 外部利用者や複数テナントのワークロードを同居させている |
| 最優先 | 信頼できないコンテナーイメージを実行する可能性がある |
| 最優先 | CI/CDサービスや委託先にPod、Job、DaemonSetの作成権限がある |
| 高 | privileged、hostPath、hostNetworkなどを使用するワークロードが多い |
| 高 | Kubernetes RBACが広く、複数の利用者が全名前空間へデプロイできる |
| 高 | クラスターのパッチ適用状況を確認できていない |
| 通常 | パッチ済みであることを確認でき、実行主体とデプロイ経路を厳格に限定している |
これらはMicrosoftが公開した悪用条件ではなく、クラスターごとの対応優先度を決めるための実務上の判断基準です。
影響バージョンの見方で注意すべき点
公開レコードでは、影響対象がv0.20260213.5未満とされています。しかし、この値は次のような管理者が普段確認する番号とは形式が異なります。
- Kubernetesバージョン：
1.34.5など - AKSノードイメージ：
AKSUbuntu-2404gen2containerd-202604.07.0など - AKSリリース：
v20260104など
そのため、az aks showで表示されるkubernetesVersionとv0.20260213.5を直接比較しても、脆弱性の有無は判断できません。ノードイメージを日付だけで比較する方法も不適切です。
AKS Vulnerability Data APIでは、AKSリリース、Kubernetesバージョン、ノードイメージ、コンテナーイメージ、OSパッケージごとのCVE情報を確認できます。ただし、このAPIは個々のクラスターをスキャンするものではなく、特定クラスターで悪用可能かどうかも判定しません。データのreport_timeが2026年6月9日以降であることも確認してください。(Microsoft Learn)
AKS管理者が最初に確認する手順
管理対象のAKSクラスターを一覧化する
まず、対象サブスクリプション内にあるAKSクラスターを洗い出します。
az aks list \
--query "[].{Name:name,ResourceGroup:resourceGroup,Location:location,Kubernetes:kubernetesVersion,State:provisioningState}" \
--output table複数のAzureサブスクリプションを使用している場合は、開発環境や停止中のクラスターも含めて確認します。停止中のノードプールも、再開時に更新対象となる可能性があるため除外しないでください。
Azure Service Healthと公式情報を確認する
次の情報を同じ時点で確認します。
- MSRCのCVE-2026-32193ページ
- Azure Service Healthのセキュリティ通知
- AKSのSecurity Bulletins
- AKS Release Status
- Azure Advisorの更新・廃止に関する推奨事項
- Microsoft Defender for Cloudの推奨事項とアラート
Azure Service Healthに対象リソース、必要な操作、期限が表示されている場合は、一般公開情報よりも自分のテナントに届いた指示を優先します。
クラスターと自動更新の設定を記録する
az aks show \
--resource-group <リソースグループ名> \
--name <AKSクラスター名> \
--query "{kubernetesVersion:kubernetesVersion,autoUpgradeProfile:autoUpgradeProfile}" \
--output yaml続けて、各ノードプールのKubernetesバージョンとノードイメージを取得します。
az aks nodepool list \
--resource-group <リソースグループ名> \
--cluster-name <AKSクラスター名> \
--query "[].{Pool:name,Kubernetes:orchestratorVersion,NodeImage:nodeImageVersion}" \
--output tableこの出力は、対応前後の証跡として保存しておくと、監査やインシデント報告にも利用できます。
ワークロードを作成できる主体を確認する
今回の公開情報では低い権限が必要とされているため、「誰がクラスター内でコードを実行できるか」の確認が重要です。
サービスアカウントのPod作成権限は、次のように確認できます。
kubectl auth can-i create pods \
--all-namespaces \
--as=system:serviceaccount:<名前空間>:<サービスアカウント名>併せて、次の主体を棚卸しします。
- Azure DevOpsやGitHub ActionsなどのCI/CD ID
- 外部委託先や開発者グループ
- GitOpsオペレーター
- HelmやKubernetes Operator
- 全名前空間へデプロイできるサービスアカウント
- 長期間使用されていないClusterRoleBinding
不要なPod作成権限や、広すぎるClusterRoleBindingは、パッチ確認と並行して縮小します。
不審な操作がないかログを確認する
公開情報にはCVE固有の侵害痕跡は示されていません。そのため、一般的なKubernetesの異常操作として次を確認します。
- Pod、Job、CronJob、DaemonSetの不審な作成や変更
kubectl execに相当する操作の急増privilegedやhostPathを新たに使用したPod- サービスアカウントやClusterRoleBindingの変更
- Azure Activity Log上のAKS・ノードプール変更
- Microsoft Defender for Containersのランタイムアラート
- 想定外のコンテナーイメージやレジストリの使用
ログが保存されていない場合は、少なくともAzure Activity Log、Kubernetesイベント、CI/CDの実行履歴を確認します。
CVE-2026-32193のパッチ対応で何を更新すべきか
現時点の公開CVEレコードだけでは、修正がAKSプラットフォーム、Kubernetesバージョン、ノードイメージ、アドオンのどこに対応するかを、顧客側のバージョンへ一意に変換できません。
そのため、対応は次の順序で判断します。
| Microsoftからの案内 | 管理者の対応 |
|---|---|
| AKSプラットフォーム側で修正済み | 対象クラスターへの展開状況を確認し、証跡を保存する |
| 特定のAKSリリースが必要 | AKS Release Statusとリージョン展開状況を確認する |
| Kubernetes更新が必要 | az aks get-upgradesで更新先を確認し、検証環境から更新する |
| ノードイメージ更新が必要 | 現在と最新のノードイメージを比較して更新する |
| 顧客側の操作が明記されていない | 推測で更新せず、Service Healthを確認し、高リスク環境はMicrosoftサポートへ照会する |
ノードイメージ更新を指示された場合
利用可能な最新ノードイメージを確認します。
az aks nodepool get-upgrades \
--resource-group <リソースグループ名> \
--cluster-name <AKSクラスター名> \
--nodepool-name <ノードプール名>現在のノードイメージは次のコマンドで確認できます。
az aks nodepool show \
--resource-group <リソースグループ名> \
--cluster-name <AKSクラスター名> \
--name <ノードプール名> \
--query nodeImageVersionMicrosoftからノードイメージ更新が対策として指定された場合は、全ノードプールを更新できます。
az aks upgrade \
--resource-group <リソースグループ名> \
--name <AKSクラスター名> \
--node-image-only \
--yesこれらはAKSの標準的なノードイメージ確認・更新手順です。CVE-2026-32193の修正がノードイメージに含まれると確認できるまでは、ノードイメージ更新だけで対策完了と判断しないでください。 (Microsoft Learn)
Kubernetes更新を指示された場合
更新可能なバージョンを確認します。
az aks get-upgrades \
--resource-group <リソースグループ名> \
--name <AKSクラスター名> \
--output table本番環境を先に更新せず、同じアドオン、Operator、Admission Policyを使用する検証環境で動作確認してから展開します。
自動更新の設定も併せて見直す
AKSでは、Kubernetesの自動アップグレードとノードOSイメージの自動更新が別々に管理されます。片方だけを有効にしても、すべての更新を自動適用できるわけではありません。
たとえば、Kubernetesの同一マイナーバージョン内で最新パッチを適用するには、patchチャネルを利用できます。
az aks update \
--resource-group <リソースグループ名> \
--name <AKSクラスター名> \
--auto-upgrade-channel patchノードイメージの更新には、Node OS自動アップグレードチャネルを設定します。
az aks update \
--resource-group <リソースグループ名> \
--name <AKSクラスター名> \
--node-os-upgrade-channel NodeImageMicrosoftは、最新パッチを早く適用したい場合にpatchチャネルを案内し、ノードイメージについてはNodeImageチャネルとの併用を示しています。自動更新を使う場合、計画メンテナンスの時間枠は4時間以上が推奨されています。(Microsoft Learn)
ただし、自動更新を有効にすることと、CVE-2026-32193がすでに修正されていることは別です。実際のAKSリリースと適用状況を確認する必要があります。
更新時に失敗しやすいポイント
PodDisruptionBudgetが厳しすぎる
ノード更新では、Podを別ノードへ退避させるdrain処理が行われます。PodDisruptionBudgetの設定が厳しすぎると、Podを退避できず更新が停止します。
たとえば、レプリカ数が1にもかかわらずminAvailable: 1を設定すると、対象Podを停止できません。事前にレプリカ数、PDB、Topology Spread Constraintsを確認してください。
サージノード用のクォータやIPが不足する
AKSのローリング更新では、一時的に追加ノードが作成されます。vCPUクォータ、VM数、サブネットのIPアドレスが不足していると、更新が進まない場合があります。
maxSurgeを増やすと更新時間を短縮できますが、一時的なコンピューティング料金と必要IP数も増えます。
検証環境と本番環境の構成が違う
検証環境だけ古いOperatorを使っていない、Admission Policyが無効、ノードOSが異なるといった状態では、本番更新の事前検証になりません。
Kubernetesバージョンだけでなく、次の構成もそろえます。
- ノードOSとVMサイズ
- Ingress Controller
- CSIドライバー
- Service Mesh
- Azure Policy
- Defender関連コンポーネント
- GitOpsや各種Operator
MicrosoftのAKS更新ガイドでも、PDB、サージ容量、クォータ、IPアドレス、検証環境の確認が重要とされています。(Microsoft Learn)
設定・移行・料金・期限に関する疑問
| 疑問 | 現時点での判断 |
|---|---|
| 新しい設定は必須か | CVE公開情報では、新たな必須設定は案内されていない |
| Kubernetes更新は必須か | 公開CVEレコードだけでは判断できない |
| ノードイメージ更新で直るか | 修正対象として明示されるまでは断定できない |
| 新しいAKSクラスターへの移行が必要か | 強制移行や再作成は公開情報で案内されていない |
| 料金は増えるか | CVE自体に対する新料金の案内はない |
| 対応期限はあるか | 公開情報では一律の移行期限は示されていない |
更新作業では、サージノード、検証クラスター、ログ保存などに通常のAzure料金が発生する可能性があります。また、Node OSのSecurityPatchチャネルは、VHDをリソースグループへ保存するため少額の料金が発生するとMicrosoftが説明しています。(Microsoft Learn)
期限が公開されていなくても、対応を先送りしてよいという意味ではありません。Service Healthに個別期限がある場合はその日付を優先し、期限がない場合でも高リスククラスターから直ちに確認を始めます。
よくある質問
kubectlを最新版にすれば対策できますか
できません。kubectlは管理端末側のクライアントです。更新しても、AKSプラットフォーム、Kubernetesコンポーネント、ノードイメージは修正されません。
AKSを再起動すれば脆弱性は解消しますか
単純な再起動だけでは、修正済みコンポーネントへ置き換わるとは限りません。Microsoftが指定するAKSリリース、Kubernetesバージョン、ノードイメージのいずれかを適用する必要があります。
すべてのAKSクラスターが攻撃可能ですか
公開情報だけでは、すべてのクラスターが同じ条件で悪用可能とは判断できません。実際のリスクは、AKSリリースの展開状況、ワークロード、権限、Admission Policy、攻撃者が取得済みの足場などによって変わります。
Defender for Containersを有効にすればパッチされますか
Defender for Containersは、脆弱性の検出、推奨事項、ランタイムアラートの確認に役立ちますが、AKSのプラットフォームやノードイメージを自動的に修正する機能とは別です。
AKS Vulnerability Data APIに表示されなければ安全ですか
表示されないだけでは安全と判断できません。APIはクラスター固有の状態をスキャンせず、データの更新時刻やリージョンごとのロールアウト状況も考慮する必要があります。AKS Component Insights、Service Health、実際のクラスター情報と組み合わせて判断します。(Microsoft Learn)
管理者が今すぐ行うべきこと
CVE-2026-32193への対応では、次の順序を守ることが重要です。
- 全サブスクリプションのAKSクラスターを一覧化する
- 外部利用者、CI/CD、広いPod作成権限があるクラスターを優先する
- Azure Service Health、MSRC、AKS Security Bulletinsを確認する
- Kubernetesバージョン、ノードイメージ、自動更新設定を証跡として保存する
- Microsoftが指定したコンポーネントだけを検証環境から更新する
- 対応後にPod、ノード、アプリケーション、セキュリティログを再確認する
特に、v0.20260213.5をKubernetesバージョンと誤認しないことが重要です。公開情報だけで修正対象を特定できない場合は、推測で大規模更新を行わず、高リスククラスターについてMicrosoftサポートへ修正展開状況を照会してください。
コメント