MENU

Azure CVE-2026-31431対応まとめ：AKS Linuxノードの影響範囲と確認手順

Azure

2026年5月2日前後に確認された Azure documentation update: Add advisory for CVE-2026-31431 vulnerability で最も重要なのは、AKSのLinuxノードを運用している場合、既存ノードが未保護のまま残っている可能性がある点です。今回の更新では、Linux kernelのalgif_aeadモジュールに起因するローカル権限昇格の脆弱性「CVE-2026-31431（Copy Fail）」について、AKS向けの影響範囲と緩和策がAzure Kubernetes Serviceのセキュリティ情報に追加されました。AKSでLinuxノードプールを使っている管理者は、まずノードイメージ、OS SKU、緩和設定の有無を確認し、必要に応じてノードイメージアップグレードまたは自己緩和策を適用するべきです。(Microsoft Learn)

目次

今回のAzure documentation updateで何が変わったのか

今回の更新は、Azure Kubernetes Service（AKS）のセキュリティ情報に AKS-2026-0003 として、CVE-2026-31431に関するアドバイザリを追加するものです。Microsoft LearnのAKS Security bulletinsでは、2026年5月1日公開の情報として、Linux kernelのalgif_aeadモジュールに影響するローカル権限昇格の脆弱性、CVSS 3.1スコア7.8（High）、影響を受けるAKS Node Image、緩和策が整理されています。(Microsoft Learn)

確認項目更新内容AKS管理者への意味
追加された情報AKS Security bulletinsにCVE-2026-31431のアドバイザリを追加AKSのLinuxノードを棚卸しして、影響有無を判断する必要がある
脆弱性の種類Linux kernelのalgif_aeadモジュールに関するローカル権限昇格Podやコンテナ内でコード実行された場合、ノード側の権限昇格につながる可能性がある
影響コンポーネントAKS Node ImageKubernetesのバージョンだけでなく、ノードOSイメージの状態を見る必要がある
主な緩和策modprobe設定でalgif_aeadの自動ロードをブロックカーネルパッチ適用前でも、モジュールの自動ロードを防ぐ対策が重要
既存ノードの注意点ホットフィックス適用前に作成された既存ノードは未保護の可能性新規ノードだけでなく、稼働中ノードの確認と再イメージ化が必要

この更新を「ドキュメントが増えただけ」と捉えるのは危険です。実務上は、AKSクラスタの運用手順に ノード単位の確認、ノードイメージ更新、緩和策の適用確認 を追加する必要があります。

CVE-2026-31431とは何か

CVE-2026-31431は「Copy Fail」と呼ばれるLinux kernelの脆弱性です。影響を受けるコンポーネントは、Linux kernelの暗号関連モジュールであるalgif_aeadです。Canonicalの情報では、2026年4月29日に公開されたローカル権限昇格の脆弱性として説明されており、Ubuntu 26.04より前のリリースに影響する可能性があるとされています。([Ubuntu][2])

この脆弱性のポイントは、インターネット越しに単体で直接侵入されるタイプではなく、すでに何らかの形でローカルにコードを実行できる攻撃者が、root権限へ昇格するリスク だという点です。AKSでは「ローカルにコードを実行できる状態」が、侵害されたPod、悪意あるワークロード、CI/CDジョブ、マルチテナント環境のコンテナ実行などで現実的に発生し得ます。Microsoft Security Blogでも、コンテナやKubernetes環境では、ホストカーネルを共有するため影響範囲がノード全体に広がる可能性があると説明されています。(Microsoft)

重要なのは、Podが非rootで動いているだけでは十分な防御にならない ことです。AKS Advisoryでは、特別なPod権限、capability、host accessがなくても、非root Podからの影響が確認されたと説明されています。(GitHub)

影響を受けるAKS環境

Microsoft LearnのAKS Security bulletinsでは、影響コンポーネントとしてAKS Node Imageが挙げられ、「現在のAKS Linuxノードは影響を受ける」と説明されています。また、algif_aeadがデフォルトでロードされていなくても、AF_ALGソケットのAEADタイプが作成されると、Linux kernelのモジュール自動ロード機構によって読み込まれる可能性があるとされています。(Microsoft Learn)

ノードOS掲載されているカーネル例影響
Ubuntu 20.04 FIPS5.4.0-1160-azure-fips影響あり
Ubuntu 22.045.15.0-1102-azure影響あり
Ubuntu 24.046.8.0-1052-azure影響あり
AzureLinux 3.06.6.130.1-3.azl3影響あり
AzureLinux 2.0（Mariner）該当なしこのアドバイザリ上は影響なし
Windowsノード該当なしこのアドバイザリ上は影響なし

この表で注意したいのは、FIPS構成や非rootコンテナでも自動的に安全とは言えない点です。Ubuntu 20.04 FIPSも影響対象として掲載されています。FIPSは暗号モジュールの検証や運用要件に関係するものであり、今回のようなカーネルモジュールの権限昇格リスクを無条件に回避するものではありません。

優先的に確認すべきクラスタ

次の条件に当てはまるAKSクラスタは、優先度を上げて確認してください。

環境優先度理由
Linuxノードプールを持つAKSクラスタ高今回の主対象がAKS Linuxノードのため
CI/CDランナー、ビルドPod、ジョブ実行基盤をAKS上で動かしている高外部由来のコードを実行する機会が多い
マルチテナント型のKubernetes運用をしている高1つのPod侵害がノード全体のリスクになりやすい
インターネット公開アプリをAKS上で運用している中〜高アプリ侵害後の権限昇格に悪用される可能性がある
Windowsノードのみのクラスタ低今回のAKSアドバイザリではWindowsノードは非影響
AzureLinux 2.0のみのクラスタ低〜中今回のCVEでは非影響とされるが、別途サポートライフサイクル確認は必要

まず実施すべき確認手順

最初にやるべきことは、クラスタ内のノードプールを棚卸しし、Linuxノードがあるか、ノードイメージが更新済みか、algif_aeadの自動ロードをブロックする設定が入っているかを確認することです。

ノードプールのOSとノードイメージを確認する

AKSクラスタのノードプール情報を確認します。

az aks show \
  --resource-group <resource-group> \
  --name <cluster-name> \
  --query "agentPoolProfiles[].{name:name, osType:osType, osSku:osSku, nodeImageVersion:nodeImageVersion}" \
  -o table

ノードごとの情報は、Kubernetes側からも確認できます。

kubectl get nodes -o wide

ノードイメージのラベルを確認する場合は、次のコマンドが便利です。Microsoft Learnのノードイメージアップグレード手順でも、ノードのkubernetes.azure.com/node-image-versionラベルを確認する方法が紹介されています。(Microsoft Learn)

kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.metadata.labels.kubernetes\.azure\.com/node-image-version}{"\n"}{end}'

ここで見るべきポイントは、Kubernetesのバージョンではなく ノードOSイメージ です。今回のCVEはAKS Node Imageに関する問題として扱われているため、「AKSのKubernetesバージョンが新しいから大丈夫」と判断しないでください。

Node OS Upgrade Channelを確認する

現在のNode OS Upgrade Channelは次のコマンドで確認できます。

az aks show \
  --resource-group <resource-group> \
  --name <cluster-name> \
  --query "autoUpgradeProfile.nodeOsUpgradeChannel" \
  -o tsv

AKSのNode OS自動アップグレードには、None、Unmanaged、SecurityPatch、NodeImageなどのチャネルがあります。Microsoft Learnでは、新しいAKSクラスタの既定値はNodeImageで、NodeImageは週次のVHD更新、SecurityPatchはAKSでテストされたOSセキュリティパッチを適用するチャネルとして説明されています。(Microsoft Learn)

ただし、チャネルを確認するだけでは不十分です。今回のAKS Advisoryでは、ホットフィックス適用前に作成された既存ノードは未保護のまま残る可能性があり、ノードイメージアップグレードまたは自己緩和策の適用が推奨されています。(GitHub)

algif_aeadの緩和設定を確認する

AKS Advisoryでは、kubectl debugを使ってノード上のmodprobe設定を確認する方法が示されています。以下は、ノードにデバッグコンテナで入って確認する例です。(GitHub)

kubectl debug node/<node-name> -it --image=mcr.microsoft.com/cbl-mariner/busybox:2.0

デバッグコンテナ内で、ホストファイルシステムは/host配下に見えます。

grep -qs "algif_aead" /host/etc/modprobe.d/*.conf \
  && echo "Mitigation is active" \
  || echo "No mitigation found"

grep -qE '^algif_aead ' /host/proc/modules \
  && echo "Module is loaded" \
  || echo "Module is not loaded"

結果の見方は次の通りです。

確認結果判断次の対応
Mitigation is active かつ Module is not loaded緩和策は有効と判断しやすいノードイメージ更新計画を確認し、記録を残す
Mitigation is active だが Module is loadedモジュールが残っている可能性ノード再起動、再イメージ化、公式手順に沿った確認が必要
No mitigation found未保護の可能性が高いノードイメージアップグレードまたは自己緩和策を優先
Windowsノード今回の確認対象外Linuxノードプールの有無を再確認

特に注意すべきなのは、Module is not loadedだけでは安全とは言い切れない点です。AKSの説明では、algif_aeadがデフォルトでロードされていなくても、条件次第で自動ロードされ得るとされています。つまり、「今ロードされていない」ではなく「自動ロードをブロックできているか」 を確認する必要があります。(Microsoft Learn)

推奨される対応方針

対応の基本は、次の順番で進めるのが実務的です。

| 手順 | 作業 | 目的 |
| -: | ———————————— | ———————— |
| 1 | AKSクラスタとノードプールを棚卸しする | Linuxノードプールの有無を把握する |
| 2 | ノードイメージとNode OS Upgrade Channelを確認する | 自動更新に任せられるか、手動対応が必要か判断する |
| 3 | algif_aeadの緩和設定を確認する | 既存ノードが保護されているか確認する |
| 4 | 未保護ノードにノードイメージアップグレードを実施する | ホットフィックス済みイメージへ移行する |
| 5 | すぐに再イメージ化できない場合は自己緩和策を適用する | 短期的なリスクを下げる |
| 6 | 適用後に再確認し、運用記録を残す | 監査・再発防止・チーム共有に使う |

ノードイメージアップグレードを実施する

AKSのノードイメージ更新は、Kubernetesバージョンを上げずに実行できます。Microsoft Learnでは、クラスタ全体のノードイメージを更新する場合に、az aks upgradeへ--node-image-onlyを付ける手順が示されています。(Microsoft Learn)

az aks upgrade \
  --resource-group <resource-group> \
  --name <cluster-name> \
  --node-image-only \
  --yes

特定のノードプールだけを更新する場合は、次のように実行します。

az aks nodepool upgrade \
  --resource-group <resource-group> \
  --cluster-name <cluster-name> \
  --name <nodepool-name> \
  --node-image-only

本番環境では、実行前にPodDisruptionBudget、メンテナンスウィンドウ、max-surge、ステートフルワークロードの退避可否を確認してください。ノードイメージアップグレードはノードの入れ替えや再イメージ化を伴うため、アプリケーション側の冗長性が不足していると、セキュリティ対応がサービス停止につながる可能性があります。

すぐにノードを更新できない場合は自己緩和策を検討する

AKS Advisoryでは、既存ノード向けに自己緩和用のDaemonSetが案内されています。このDaemonSetは、ホスト側の/etc/modprobe.d/にalgif_aeadの自動ロードをブロックする設定を入れ、必要に応じてロード済みモジュールのアンロードを試みるものです。(GitHub)

緩和策の考え方は、次のmodprobe設定に集約されます。

install algif_aead /bin/false
blacklist algif_aead

ただし、公式のDaemonSetは特権コンテナとしてホストファイルシステムに変更を加えるため、適用前に次の点を確認してください。

注意点実務での確認ポイント
特権DaemonSetが必要Pod Security、Admission Controller、Azure Policyでブロックされないか確認する
すべてのLinuxノードに展開されるnodeSelectorやtolerationsが意図した対象になっているか確認する
既存アプリへの影響があり得るハードウェアアクセラレーション付きAEAD暗号を直接使うワークロードがないか確認する
モジュールが使用中だとアンロードできない場合があるログを確認し、必要ならノード再起動や再イメージ化を計画する
恒久対策ではなく暫定策として扱う最終的にはホットフィックス済みノードイメージやカーネル更新へ移行する

Canonicalも、kmodパッケージによる緩和策としてalgif_aeadモジュールの無効化を案内しており、すでに稼働しているアプリケーションへの影響や、モジュールが使用中の場合に再起動が必要になる可能性を説明しています。([Ubuntu][2])

新規ノードと既存ノードで対応が違う

今回の更新で見落としやすいのが、新規ノードと既存ノードの扱いの違いです。

AKS Advisoryでは、緩和策は新しいVHDやノードプロビジョニング時の処理を通じて適用される一方、ホットフィックス展開前に作成され、再イメージ化されていない既存ノードは未保護の可能性があると説明されています。2026年5月1日時点で、v20260413とv20260424向けのホットフィックス展開にも言及されています。(GitHub)

ノードの状態判断推奨対応
ホットフィックス後に新規作成されたLinuxノード保護されている可能性が高いそれでも緩和設定を確認する
ホットフィックス前から稼働しているLinuxノード未保護の可能性ありノードイメージアップグレードまたは自己緩和策を実施
ノードイメージアップグレード済み保護状態を確認すべきmodprobe設定とノードイメージラベルを記録
すぐに入れ替えられない本番ノード暫定対応が必要公式DaemonSetなどの自己緩和策を検討

つまり、「AKS側でホットフィックスが出たから終わり」ではありません。既存ノードを使い続けている場合は、ノード単位で確認する必要があります。

Node OS Upgrade Channel別の考え方

AKSのNode OS Upgrade Channelは、今回の対応計画にも関係します。

チャネル特徴今回の対応での注意点
NodeImageAKSが週次で新しいVHDを提供し、ノードイメージを更新既定値でも、既存ノードがすぐ更新済みとは限らない
SecurityPatchAKSでテストされたOSセキュリティパッチを適用セキュリティ修正の追従を重視する環境で検討しやすい
UnmanagedOS側の仕組みで更新されるが、AKSは制御しないカーネル更新後に再起動が必要になる場合がある
None自動適用なし管理者が手動で更新・再イメージ化を計画する必要がある

AKS AdvisoryのFAQでは、NodeImageでは週次VHDリリースとノードイメージアップグレードが重要であり、UnmanagedではOS側の自動更新があっても、カーネル更新を有効化するには再起動が必要になると説明されています。また、modprobeベースの緩和策は即時の防御として扱われ、今後のカーネルパッチは防御を厚くする位置づけとされています。(GitHub)

運用上は、次のように判断すると分かりやすいです。

運用方針向いている対応
セキュリティ更新をAKS管理の範囲で安定適用したいNodeImageまたはSecurityPatchを使い、メンテナンスウィンドウを設定
緊急CVEへの追従速度を重視したいSecurityPatchの採用可否を検討
自社でOS更新・再起動を厳密に制御したいNoneやUnmanagedの責任範囲を明確化し、手動手順を整備
本番影響を最小化したいmax-surge、PodDisruptionBudget、複数ノードプール設計を見直す

失敗しやすい判断と注意点

コンテナイメージを更新してもホストカーネルは直らない

今回の脆弱性は、コンテナイメージ内のライブラリだけの問題ではありません。AKSノードのLinux kernelとノードイメージが重要です。アプリケーションのコンテナイメージを再ビルドしても、ホスト側のカーネルやmodprobe設定が未対応なら、根本的な対応にはなりません。

非root Podだから安全とは判断しない

AKS Advisoryでは、非root Podからの影響が確認されたと説明されています。KubernetesのSecurityContextでrunAsNonRootを設定していることは重要ですが、今回の脆弱性に対しては十分条件ではありません。(GitHub)

algif_aeadがロードされていないだけでは安心できない

今回のポイントは、モジュールが必要時に自動ロードされ得ることです。確認すべきなのは、/proc/modulesに存在しないことだけでなく、/etc/modprobe.d/配下で自動ロードをブロックする設定が入っているかです。

脆弱性スキャナーの結果だけで判断しない

スキャナーがカーネルパッケージのバージョンを見て「脆弱」と判定する一方で、modprobeベースの緩和策が適用済みというケースもあります。逆に、スキャナー上はまだ検出されていなくても、既存ノードに緩和設定が入っていなければリスクが残ります。

実務では、次の3点をセットで記録してください。

記録すべき項目例
ノードイメージkubernetes.azure.com/node-image-versionの値
緩和設定install algif_aead /bin/falseまたはblacklist algif_aeadの有無
ノード状態ノードイメージアップグレード済み、DaemonSet適用済み、再起動済みなど

暫定緩和策を入れたまま放置しない

自己緩和用DaemonSetは、緊急対応として有効ですが、恒久運用の設計まで代替するものではありません。ノードイメージ更新やカーネルパッチが適用できる段階になったら、緩和策の残存、削除タイミング、監査ログを整理してください。

特に、暗号処理に特殊な要件があるワークロードでは、algif_aeadを無効化した影響が出る可能性があります。Canonicalも、通常のアプリケーションはユーザー空間の暗号ライブラリへフォールバックするとしつつ、一部アプリケーションでは影響があり得ると説明しています。([Ubuntu][2])

Microsoft Defenderや監視で確認したいこと

Microsoft Security Blogでは、CVE-2026-31431について、Microsoft Defender XDR、Microsoft Defender for Endpoint、Microsoft Defender for Cloud、Microsoft Defender Vulnerability Managementによる検出や可視化にも触れています。Defender for Cloudを使っている場合は、AKSノードやLinuxホストに関連するアラート、脆弱性評価、推奨事項を確認してください。(Microsoft)

確認すべき観点は次の通りです。

監視観点確認内容
脆弱性管理CVE-2026-31431が対象ホストに出ていないか
実行検知Linux上で不審な権限昇格やPoC実行の兆候がないか
Kubernetes監査不審なkubectl exec、Job、CronJob、デバッグPodがないか
ノード変更/etc/modprobe.d/配下の変更が意図したものか
インシデント対応侵害済みPodがある場合、ノード全体を信頼し続けない判断ができているか

今回のようなローカル権限昇格では、「外部から直接攻撃されるか」だけでなく、「すでに侵害されたPodが次に何をできるか」を考える必要があります。WebアプリのRCE、漏洩したCIトークン、悪意あるビルドスクリプトなどが初期侵入になると、ノード権限昇格のリスクが一気に現実的になります。

管理者向けチェックリスト

本番環境では、次のチェックリストを使って対応漏れを減らしてください。

チェック内容完了条件
クラスタ棚卸しすべてのAKSクラスタを一覧化対象サブスクリプション全体で確認済み
Linuxノード確認Linuxノードプールの有無を確認Ubuntu、AzureLinux 3.0などを識別済み
既存ノード確認ホットフィックス前から稼働しているノードを確認ノード単位で状態を記録済み
緩和設定確認algif_aeadの自動ロードブロックを確認modprobe.d設定を確認済み
ノード更新--node-image-onlyで更新または計画本番影響を考慮して実施済み
暫定緩和すぐに更新できないノードへ公式手順で適用DaemonSetログと対象ノードを確認済み
監視確認Defenderやログで悪用兆候を確認アラート・検知・監査ログを確認済み
恒久対応カーネルパッチや最新ノードイメージへ移行暫定策の扱いまで整理済み

よくある質問

AKSのKubernetesバージョンを上げれば対応できますか

今回の主対象はAKS Node Imageです。Kubernetesバージョンアップではなく、ノードイメージアップグレードやノードOS側の緩和策が重要です。Microsoft Learnでも、ノードイメージはKubernetesバージョンを上げずに--node-image-onlyで更新できると説明されています。(Microsoft Learn)

Windowsノードも対応が必要ですか

今回のAKSアドバイザリでは、Windowsノードは影響を受けないとされています。混在クラスタの場合は、WindowsノードではなくLinuxノードプールを重点的に確認してください。(Microsoft Learn)

AzureLinux 2.0は対応不要ですか

CVE-2026-31431に関するAKSアドバイザリ上では、AzureLinux 2.0（Mariner）は影響なしとされています。ただし、AzureLinux 2.0自体のサポートライフサイクルや移行計画は別問題です。今回のCVE対応とは切り分けて、AKSのサポート状況を確認してください。

新しく作成したノードなら安全ですか

ホットフィックス後に作成されたノードは保護されている可能性が高いものの、確認は必要です。AKS Advisoryでは、新規ノードやノードイメージアップグレードを受けたノードは緩和策を受け取る一方、ホットフィックス前に作成された既存ノードは未保護の可能性があると説明されています。(GitHub)

カーネルパッチが来るまで待ってもよいですか

待つだけの判断は避けるべきです。AKSの緩和策は、algif_aeadの自動ロードをブロックすることで即時のリスクを下げるものです。Canonicalも、カーネルパッケージによる修正に加え、kmodパッケージによるモジュール無効化の緩和策を案内しています。([Ubuntu][2])

まとめ：まず既存Linuxノードを確認し、未保護なら更新または緩和する

今回のAzure documentation updateで追加されたCVE-2026-31431のアドバイザリは、AKSのLinuxノードを運用している組織にとって優先度の高い確認事項です。特に重要なのは、ホットフィックスが提供されていても、既存ノードが自動的にすべて保護済みになるとは限らない点です。

まず、AKSクラスタのLinuxノードプールを洗い出し、ノードイメージ、Node OS Upgrade Channel、algif_aeadの緩和設定を確認してください。未保護のノードがある場合は、--node-image-onlyによるノードイメージアップグレードを基本対応とし、すぐに更新できない環境では公式アドバイザリに沿った自己緩和策を適用します。

対応後は、ノードイメージのバージョン、緩和設定、再起動または再イメージ化の有無を記録し、Defenderや監査ログで悪用兆候がないかを確認してください。今回の対応は「パッチを当てる」だけでなく、AKSのノード更新運用、メンテナンスウィンドウ、Pod退避設計を見直す機会にもなります。

[2]: https://ubuntu.com/blog/copy-fail-vulnerability-fixes-available “
Fixes available for CVE-2026-31431 (Copy Fail) Linux Kernel Local Privilege Escalation Vulnerability
| Ubuntu”

Azure
セキュリティ Azure Kubernetes AKS CVE-2026-31431

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次