CVE-2026-56852とは？Azure Linux 3.0の影響確認と修正版への更新手順

CVE-2026-56852への対応で最も重要なのは、Azure Linux 3.0上にgolang.org/x/textという名前のRPMがあるかを探すことではありません。MSRCに掲載されたAzure Linux 3.0向け各パッケージの「影響するバージョン／ビルド」と「FirstFixed」を確認し、導入済みRPMの完全なバージョンと照合する必要があります。

該当する場合はFirstFixed以上の公式パッケージへ更新し、対象サービスの再起動、コンテナの再ビルドと再デプロイ、AKSノードイメージの更新まで行います。自社でビルドしたGoアプリケーションについては、golang.org/x/textをv0.39.0以降へ更新して再ビルドします。(Microsoft Security Response Center)

CVE-2026-56852の概要

CVE-2026-56852は、Goの拡張ライブラリgolang.org/x/textに含まれるUnicode正規化処理の脆弱性です。不正または途中で切れたUTF-8データを処理すると、unicode/normの反復処理が終了せず、無限ループに入る可能性があります。

項目	内容
CVE番号	CVE-2026-56852
影響するライブラリ	`golang.org/x/text/unicode/norm`
主な問題	不正なUTF-8入力による無限ループ
想定される影響	CPU消費、処理停止、サービス拒否
CVSS 3.1	7.5（High）
CVSSベクター	`AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H`
CWE	CWE-835：Loop with Unreachable Exit Condition
影響する上流バージョン	`golang.org/x/text`の`v0.39.0`未満
上流の修正版	`v0.39.0`以降
Azure Linux 3.0の判定基準	MSRCに掲載された各RPMのFirstFixed

CVSSベクターでは、攻撃元はネットワーク、攻撃条件は低複雑度、権限と利用者操作は不要と評価されています。一方、機密性と完全性への直接的な影響は示されておらず、主な影響は可用性です。(CVE Premium)

不正なUTF-8で無限ループが発生する仕組み

問題があるのは、Unicode文字列を一定の形式へそろえる正規化処理です。Go公式の脆弱性情報では、norm.Iterが不正なUTF-8バイト列を処理した際に無限ループへ入る可能性があると説明されています。(Go)

通常の反復処理は、入力位置を少しずつ進めながら、終端に達した時点で終了します。しかし、この脆弱性では特定の不正入力を処理した際に入力位置が進まない状態となり、同じ処理を繰り返す可能性があります。

Goのstringは必ずしも正しいUTF-8であるとは限りません。HTTPリクエスト、ファイル、メッセージキュー、外部APIなどから受け取ったバイト列を十分に検証せず、Unicode正規化処理へ渡している場合は注意が必要です。

公式のGo脆弱性データベースでは、Iter関連だけでなく、Form.String、Form.Transform、Form.IsNormalなど、正規化処理に関連する複数のシンボルが影響対象として示されています。アプリケーションがnorm.Iterを直接呼んでいなくても、別のAPIを経由して問題のある処理へ到達する可能性があります。(Go Packages)

RCEではなく可用性を狙う脆弱性

CVE-2026-56852について公表されている主な影響は、任意コード実行や権限昇格ではありません。

想定されるのは、次のようなサービス拒否です。

リクエスト処理が完了しない
GoプロセスがCPUを消費し続ける
処理待ちが増え、応答時間が悪化する
同様の入力を繰り返され、サービス全体が利用しにくくなる
Kubernetes環境でCPU制限に達し、Podの性能が大きく低下する

CVSSが7.5だからといって、直ちに「リモートコード実行の脆弱性」と判断するのは誤りです。一方、インターネットから不特定の入力を受け取るサービスでは、1件の異常入力が長時間のCPU消費につながる可能性があるため、早期対応が必要です。

優先して確認すべきシステム

次のような処理を持つ環境は、優先度を高くして確認します。

優先度	確認対象の例
高	公開API、Webサービス、APIゲートウェイ、ファイルアップロード機能
高	利用者名、組織名、ID、URL、検索文字列などをUnicode正規化するサービス
高	外部から受信した文書、CSV、JSON、ログ、メッセージを処理するワーカー
中	社内限定サービスだが、取引先や外部システムのデータを取り込む処理
中	Kubernetesコントローラー、エージェント、監視ツール、コンテナ関連ツール
低め	管理者だけが信頼済みデータを入力するローカルCLI

「低め」は更新不要という意味ではありません。外部入力から脆弱な処理までの到達経路が少ないため、緊急度を相対的に下げられる可能性があるという判断です。

Azure Linux 3.0では各RPMパッケージの確認が必要

golang.org/x/textはGoモジュールであり、Azure Linux上で独立したRPMとしてインストールされているとは限りません。

Goで作られたアプリケーションは、ビルド時に依存ライブラリのコードを実行ファイルへ組み込むことが一般的です。そのため、脆弱なx/textを利用してビルドされたソフトウェアは、アプリケーション自身のRPMを再ビルドしなければ修正されません。

つまり、次の確認方法では不十分です。

rpm -qa | grep x/text

このコマンドで何も見つからなくても、Go製アプリケーションのバイナリ内部に脆弱なx/textが含まれている可能性があります。

MSRCがAzure Linux 3.0向けに複数のパッケージ行を掲載するのは、このためです。利用者はgolangパッケージだけでなく、MSRCの対象表にあるアプリケーション、CLI、エージェント、コンテナ関連ツールなどを個別に確認する必要があります。(Microsoft Security Response Center)

FirstFixedの正しい読み方

FirstFixedは、Microsoftがそのパッケージについて「修正を含む最初のビルド」として示した値です。

重要なのは、CVE-2026-56852に対するFirstFixedが1つではない点です。パッケージごとに元のアプリケーションバージョンやRPMリリース番号が異なるため、MSRCの各行に示された値を使用します。

上流のv0.39.0とAzure LinuxのFirstFixedは別の基準

次の2つを混同しないようにしてください。

対象	修正済みの判断基準
自社でビルドするGoアプリ	`golang.org/x/text`が`v0.39.0`以降
Microsoftが提供するAzure Linux RPM	MSRCの該当パッケージに記載されたFirstFixed以上

Microsoftが上流修正を既存バージョンへバックポートした場合、アプリケーション本体のバージョンが変わらず、RPMのReleaseだけが増えることがあります。

比較の考え方は次のとおりです。

導入済み:   package-name-1.12.15-10.azl3.x86_64
FirstFixed: package-name-1.12.15-11.azl3.x86_64

この例では、上流バージョンの1.12.15は同じですが、RPMリリースが10から11へ更新されています。1.12.15だけを見れば同じバージョンに見えますが、導入済みの-10は修正前です。

確認する項目は次の5つです。

項目	確認理由
Name	同名に見える別パッケージとの混同を防ぐ
Epoch	RPMのバージョン比較で最優先される場合がある
Version	ソフトウェア本体のバージョン
Release	Azure Linux側の再ビルドやバックポートを識別する
Architecture	`x86_64`と`aarch64`などを区別する

バージョンを単純な文字列として比較してはいけません。例えば文字列比較では、1.10が1.9より古いと誤判定されることがあります。RPMのEpoch、Version、Releaseを含む比較規則で判断してください。

MSRCと導入済みパッケージを照合する手順

Azure Linux 3.0であることを確認する

最初にOSの種類とメジャーバージョンを確認します。

grep -E '^(NAME|ID|VERSION_ID)=' /etc/os-release

VERSION_IDが3.0であることを確認してください。Azure Linux 2.0、4.0、別のRPM系ディストリビューションでは、同じCVEでも修正パッケージやバージョン基準が異なります。

MSRCから確認項目を記録する

MSRCのCVE-2026-56852ページで、Azure Linux 3.0に該当する行を確認します。各行について、最低限次の情報を記録します。

パッケージ名
対象製品がAzure Linux 3.0であること
影響するバージョンまたはビルド
FirstFixed
アーキテクチャ
更新日

FirstFixedはパッケージごとに異なり、公開後に対象行やビルド情報が追加される可能性があります。過去の画面キャプチャや二次情報だけで判断せず、更新作業時点のMSRCページを基準にします。(Microsoft Security Response Center)

導入済みRPMの一覧を取得する

変更前の証跡として、インストール済みパッケージを保存します。

rpm -qa \
  --qf '%{NAME}\t%{VERSION}-%{RELEASE}.%{ARCH}\n' \
  | sort \
  > /tmp/rpm-inventory-before.txt

MSRCに記載されたパッケージを個別に確認する場合は、package-nameを実際の名前へ置き換えます。

PACKAGE="package-name"

rpm -q "$PACKAGE"

Epochを含めて確認するには、次の形式が便利です。

rpm -q \
  --qf 'name=%{NAME}\nepoch=%{EPOCH}\nversion=%{VERSION}\nrelease=%{RELEASE}\narch=%{ARCH}\n' \
  "$PACKAGE"

パッケージが導入されていなければ、RPMは未インストールであることを示します。ただし、その結果で分かるのは「そのパッケージ経由では影響を受けない」ということだけです。

別の対象RPM、コンテナ内部のパッケージ、自社ビルドしたGoバイナリについても、引き続き確認が必要です。

実行ファイルがどのRPMに属するか調べる

サービス名、コマンド名、RPM名が一致しないことがあります。実行ファイルの所有パッケージは、次のコマンドで確認できます。

BINARY="/path/to/binary"

rpm -qf "$BINARY"

スキャナーが実行ファイル名だけを通知しており、更新すべきパッケージ名が分からない場合に有効です。

判定結果を整理する

確認結果	判定
MSRC記載のパッケージが未導入	そのRPMに関する更新は不要
影響範囲内でFirstFixed未満	更新が必要
FirstFixedと同一	修正済み
同じ公式更新系列でFirstFixedより新しい	通常は修正を包含
別アーキテクチャや別ブランチ	直接比較せず、対応するMSRC行を確認
独自RPMや第三者リポジトリ	MicrosoftのFirstFixedだけでは判定不可
ホストにはないがコンテナに存在	コンテナイメージの再ビルドが必要
RPMではなく自社製Goバイナリ	Goモジュールのバージョンを確認

Azure Linux 3.0の修正版へ更新する方法

Azure Linux 3.0では、パッケージ管理にTiny DNFのtdnfを使用します。(Microsoft Learn)

対象パッケージだけを更新する場合は、次のコマンドを実行します。

PACKAGE="package-name"

sudo tdnf upgrade "$PACKAGE"

トランザクションの内容を確認し、依存パッケージの更新範囲も確認してから確定します。

システム全体の更新が組織の保守方針で認められている場合は、利用可能な更新をまとめて適用できます。

sudo tdnf upgrade

更新後、再度バージョンを確認します。

rpm -q "$PACKAGE"

出力された完全なRPMバージョンが、同じパッケージ、アーキテクチャ、更新系列におけるFirstFixed以上であることを確認します。

FirstFixedが更新候補に表示されない場合

必要な修正版が取得できない場合は、無理に外部サイトからRPMを入手せず、次の点を確認します。

Azure Linux 3.0用の正しいリポジトリが有効か
パッケージが除外設定やバージョン固定の対象になっていないか
使用中のアーキテクチャとMSRCの対象行が一致しているか
ミラーや更新チャネルに修正版が反映されているか
古いリポジトリメタデータを参照していないか

キャッシュを消去して再確認する場合は、次のように実行します。

sudo tdnf clean all
sudo tdnf upgrade "$PACKAGE"

署名や依存関係を確認できない非公式RPMを導入すると、サポート対象外の構成になったり、別の脆弱性を持ち込んだりする可能性があります。

更新後は対象プロセスを再起動する

RPMファイルを更新しても、すでに起動中のプロセスはメモリ上の古いコードを実行し続けます。常駐サービスの場合は、保守手順に従って再起動します。

SERVICE="service-name.service"

sudo systemctl restart "$SERVICE"
sudo systemctl --no-pager --full status "$SERVICE"

コマンド実行時だけ起動するCLIであれば、通常は次回の実行から新しいバイナリが使われます。

一方、デーモン、監視エージェント、コンテナランタイムなどの基盤コンポーネントを更新する場合は、関連サービスへの影響を確認し、必要に応じてローリング再起動やホスト再起動を行います。

AKSノードでの対応

AKSのAzure Linuxノードでは、各ノードへ個別に接続してtdnfを実行するのではなく、原則としてノードイメージを更新します。個別に加えた変更は、ノードの置き換え、スケール、再イメージ化によって失われる可能性があるためです。

使用可能なノードイメージを確認します。

AKS_RESOURCE_GROUP="resource-group"
AKS_CLUSTER="cluster-name"
AKS_NODEPOOL="nodepool-name"

az aks nodepool get-upgrades \
  --nodepool-name "$AKS_NODEPOOL" \
  --cluster-name "$AKS_CLUSTER" \
  --resource-group "$AKS_RESOURCE_GROUP"

現在のノードイメージは次のコマンドで確認できます。

az aks nodepool show \
  --resource-group "$AKS_RESOURCE_GROUP" \
  --cluster-name "$AKS_CLUSTER" \
  --name "$AKS_NODEPOOL" \
  --query nodeImageVersion

特定のノードプールについて、Kubernetesのバージョンを変えずにOSイメージだけを更新する場合は、次のコマンドを使用します。

az aks nodepool upgrade \
  --resource-group "$AKS_RESOURCE_GROUP" \
  --cluster-name "$AKS_CLUSTER" \
  --name "$AKS_NODEPOOL" \
  --node-image-only

更新後は、各ノードに新しいイメージが適用されたことを確認します。

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

これらはMicrosoftが案内しているAKSノードイメージの確認・更新方法です。(Microsoft Learn)

ただし、ノードイメージの更新で修正されるのはノードOS側です。Podが使用するコンテナイメージ内のGoバイナリやRPMは、自動では更新されません。

Azure Linux 3.0ベースのコンテナを修正する

ホストOSを更新しても、既存コンテナイメージのレイヤーは変化しません。コンテナ内に該当パッケージがある場合は、イメージを再ビルドします。

対応の流れは次のとおりです。

Azure Linux 3.0のベースイメージまたはダイジェストを更新する
ビルド時に公式リポジトリから修正版RPMを取得する
完成したイメージ内でRPMバージョンを確認する
SBOMと脆弱性スキャン結果を更新する
新しい不変タグまたはダイジェストでイメージを公開する
Deployment、Job、サービスなどを再デプロイする
古いイメージを使用するPodが残っていないことを確認する

実行中のコンテナへ入り、その場でtdnf upgradeするだけでは不十分です。コンテナが再作成されると変更が失われ、CI/CDから同じ状態を再現できません。

Kubernetes環境では、次の2層を分けて管理してください。

更新対象	対応
AKSノードのAzure Linux	ノードイメージを更新
Pod内のAzure Linux／Goアプリ	コンテナイメージを再ビルドして再デプロイ

自社ビルドしたGoアプリを確認する

社内開発したGoアプリケーションは、MSRCのAzure Linux RPM一覧に含まれない場合があります。その場合は、バイナリまたはソースコードからgolang.org/x/textのバージョンを確認します。

バイナリにGoのビルド情報が残っている場合は、次のコマンドを使用できます。

go version -m /path/to/application \
  | grep 'golang.org/x/text'

ソースコードのディレクトリでは、モジュール一覧を確認します。

go list -m all \
  | grep '^golang.org/x/text '

v0.39.0未満が含まれている場合は、互換性を確認したうえで修正版へ更新します。

go get golang.org/x/[email protected]
go mod tidy
go test ./...

v0.39.0より新しい互換バージョンを採用できる場合は、最新のサポート対象バージョンを使用します。更新後はバイナリを再ビルドし、旧バイナリを置き換えて再デプロイします。上流のGo脆弱性情報では、v0.39.0未満が影響対象とされています。(Go Packages)

go version -mで何も表示されなくても、安全とは限りません。次の情報も確認してください。

go.mod
go.sum
vendorディレクトリ
CI/CDの依存関係ロック情報
コンテナや成果物のSBOM
ビルドログ
govulncheckなどのGo向け脆弱性検査結果

更新後に確認すべきポイント

更新コマンドが成功しただけでは、対応完了とは判断できません。

確認項目	期待する状態
RPMバージョン	MSRCのFirstFixed以上
パッケージの入手元	Azure Linux 3.0の公式更新経路
常駐プロセス	パッケージ更新後に再起動済み
サービス状態	正常稼働し、エラーや再起動ループがない
CPU使用率	異常な高止まりがない
コンテナ	新しいイメージダイジェストが全レプリカに反映
AKSノード	更新後のノードイメージへ置き換わっている
自社Goアプリ	`x/text`が`v0.39.0`以降で再ビルド済み
スキャナー	検出が解消、または修正済みバージョンの証跡がある
変更記録	更新前後のバージョン、日時、テスト結果を保存

脆弱性スキャナーが更新後もCVE-2026-56852を検出する場合は、次の可能性を調べます。

レジストリ内の古いコンテナイメージを検査している
古いPodやプロセスが残っている
RPMではなく別の自社製バイナリを検出している
インベントリキャッシュが更新されていない
Azure Linuxのバックポートを考慮せず、上流バージョンだけで判定している
別アーキテクチャや別リポジトリのパッケージを比較している

監査証跡として、MSRCのFirstFixed、更新前後のrpm -q出力、コンテナダイジェスト、AKSノードイメージの値を保存しておくと、誤検知の説明にも利用できます。

すぐに更新できない場合の暫定対策

最も確実な対応は、修正版パッケージの導入またはGoアプリの再ビルドです。保守時間をすぐに確保できない場合は、次の対策で一時的に影響を抑えます。

正規化前にUTF-8を検証する

Goアプリで入力が[]byteの場合は、unicode/utf8を使用して正当性を確認できます。

if !utf8.Valid(input) {
    return errors.New("invalid UTF-8 input")
}

stringとして受け取っている場合は、utf8.ValidStringを使用します。

重要なのは、脆弱な正規化処理を呼び出す前に検証することです。正規化後に検証しても、無限ループを防げません。

入力とリソースを制限する

リクエスト本文やアップロードファイルの最大サイズを制限する
公開エンドポイントへレート制限を設定する
同時実行数を制限する
テキスト処理を独立したワーカーへ分離する
コンテナやプロセスへCPU上限を設定する
問題のある機能を一時的に外部公開しない
信頼できない送信元からの入力を遮断する

単純なHTTPタイムアウトだけでは十分でない場合があります。ライブラリ内部のループがキャンセル状態を確認しなければ、リクエストの期限を過ぎても処理が止まらない可能性があるためです。

これらは影響を軽減するための措置であり、FirstFixedへの更新を置き換えるものではありません。

対応時によくある失敗

失敗例	問題点
`x/text`というRPMだけを探す	ライブラリがGoバイナリへ組み込まれている場合を見落とす
`golang`パッケージだけを更新する	脆弱な依存関係を含むアプリRPMが残る可能性がある
上流アプリのバージョンだけを見る	RPMのReleaseだけに修正が入る場合がある
FirstFixedを文字列比較する	RPMのバージョン順序を誤判定する可能性がある
`v0.39.0`を全RPMの基準にする	Azure Linux RPMはMSRCのパッケージ別FirstFixedで判断する
更新後にサービスを再起動しない	メモリ上で古いバイナリが動き続ける
AKSノードを手作業で更新する	再イメージ化やスケール時に変更が消える
ノードイメージだけを更新する	Pod内の脆弱なGoバイナリは残る
実行中コンテナだけを修正する	再作成時に修正が失われる
CVSS 7.5をRCEと解釈する	公表された主な影響は可用性の低下
非公式RPMを直接導入する	署名、依存関係、サポートの問題が生じる

まず実施すべき対応

CVE-2026-56852への対応は、次の順序で進めると漏れを防げます。

MSRCのCVEページで、Azure Linux 3.0向けの対象パッケージとFirstFixedを確認する
VM、AKSノード、コンテナ、自社Goアプリの4層に分けてインベントリを取得する
該当RPMをFirstFixed以上へ更新し、自社アプリはx/textをv0.39.0以降へ更新して再ビルドする
サービス再起動、コンテナ再デプロイ、AKSノードイメージ更新を行い、実際に新しいコードが動いていることを確認する

特に注意すべきなのは、「x/textというRPMが見つからないから影響なし」と判断しないことです。Azure Linux 3.0では、MSRCのパッケージ別FirstFixedとRPMのVersion・Releaseを照合し、実行中のサービスやコンテナまで更新されたことを確認して初めて対応完了となります。

この記事を書いた人

佐藤健司

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

CVE-2026-56852とは？Azure Linux 3.0の影響確認と修正版への更新手順

CVE-2026-56852の概要

不正なUTF-8で無限ループが発生する仕組み

RCEではなく可用性を狙う脆弱性

優先して確認すべきシステム

Azure Linux 3.0では各RPMパッケージの確認が必要

FirstFixedの正しい読み方

上流のv0.39.0とAzure LinuxのFirstFixedは別の基準

MSRCと導入済みパッケージを照合する手順

Azure Linux 3.0であることを確認する

MSRCから確認項目を記録する

導入済みRPMの一覧を取得する

実行ファイルがどのRPMに属するか調べる

判定結果を整理する

Azure Linux 3.0の修正版へ更新する方法

FirstFixedが更新候補に表示されない場合

更新後は対象プロセスを再起動する

AKSノードでの対応

Azure Linux 3.0ベースのコンテナを修正する

自社ビルドしたGoアプリを確認する

更新後に確認すべきポイント

すぐに更新できない場合の暫定対策

正規化前にUTF-8を検証する

入力とリソースを制限する

対応時によくある失敗

まず実施すべき対応

この記事を書いた人

コメント

コメントするコメントをキャンセル

CVE-2026-56852とは？Azure Linux 3.0の影響確認と修正版への更新手順

CVE-2026-56852の概要

不正なUTF-8で無限ループが発生する仕組み

RCEではなく可用性を狙う脆弱性

優先して確認すべきシステム

Azure Linux 3.0では各RPMパッケージの確認が必要

FirstFixedの正しい読み方

上流のv0.39.0とAzure LinuxのFirstFixedは別の基準

MSRCと導入済みパッケージを照合する手順

Azure Linux 3.0であることを確認する

MSRCから確認項目を記録する

導入済みRPMの一覧を取得する

実行ファイルがどのRPMに属するか調べる

判定結果を整理する

Azure Linux 3.0の修正版へ更新する方法

FirstFixedが更新候補に表示されない場合

更新後は対象プロセスを再起動する

AKSノードでの対応

Azure Linux 3.0ベースのコンテナを修正する

自社ビルドしたGoアプリを確認する

更新後に確認すべきポイント

すぐに更新できない場合の暫定対策

正規化前にUTF-8を検証する

入力とリソースを制限する

対応時によくある失敗

まず実施すべき対応

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル