CVE-2026-56434対策｜Azure Linux 3.0のNGINXを1.28.3-8へ更新する手順

CVE-2026-56434への対応では、Azure Linux 3.0のNGINXパッケージを1.28.3-8.azl3以上へ更新することが最優先です。MSRCが影響対象として示しているのはnginx 1.28.3-6.azl3で、個別の回避策は掲載されていません。Microsoftのパッケージリポジトリでは、x86_64とaarch64の両方に修正版1.28.3-8が公開されています。(Microsoft Security Response Center)

確認時に注意したいのは、nginx -vだけでは安全かどうかを判断できないことです。脆弱な1.28.3-6と修正版の1.28.3-8は、どちらもNGINX本体のバージョンが「1.28.3」と表示される可能性があります。必ずRPMパッケージのリリース番号まで確認してください。

CVE-2026-56434で最初に確認すべきこと

CVE-2026-56434は、NGINXのngx_http_ssi_moduleに存在するuse-after-freeの脆弱性です。SSI、リバースプロキシ、バッファリング無効化が組み合わされた構成で、上流サーバーから返されるレスポンスを攻撃者が操作できる場合に問題が発生します。(myF5)

確認項目	内容
対象OS	Azure Linux 3.0
対象パッケージ	`nginx-1.28.3-6.azl3`
修正版	`nginx-1.28.3-8.azl3`以上
対象機能	`ngx_http_ssi_module`
主な構成条件	`ssi on;`、`proxy_pass`、`proxy_buffering off;`の組み合わせ
想定される影響	NGINXワーカープロセスのメモリ内容の限定的な変更、ワーカー再起動
MSRCの個別回避策	掲載なし
推奨対応	修正版パッケージへの更新とNGINXの再起動

攻撃条件が限定されているからといって、更新を後回しにしてよいわけではありません。設定変更やアプリケーション改修によって、将来SSIやproxy_buffering offが追加される可能性もあります。対象パッケージがインストールされている場合は、設定の有無にかかわらず修正版へ更新するのが基本です。

脆弱性が成立する構成と想定される影響

SSIとリバースプロキシを組み合わせた構成が対象

公開情報から、主に次の条件が同じリクエスト処理経路で組み合わされた場合に影響が問題となります。

ssi on;によってSSI処理が有効になっている
proxy_passで上流のWebサーバーやアプリケーションへ転送している
proxy_buffering off;によって上流レスポンスのバッファリングを無効にしている
攻撃者が中間者攻撃などによって上流レスポンスを操作できる

単に設定ファイル内に3つのディレクティブが存在するだけでは、直ちに脆弱な処理経路が成立するとは限りません。別々のserverブロックやlocationブロックに記述されている場合もあるため、実際に同じURLの処理で組み合わされているかを確認する必要があります。

use-after-freeとは何か

use-after-freeは、プログラムが解放済みのメモリ領域を再び参照してしまう問題です。解放後の領域に別のデータが割り当てられていると、異常終了や意図しないメモリ操作につながる可能性があります。

CVE-2026-56434では、影響範囲はNGINXのデータプレーン側にあるワーカープロセスとされています。公開情報で示されている主な影響は、メモリ内容の限定的な変更やワーカーの再起動です。一般的な設定のNGINXへ接続するだけで直ちに任意コード実行できる、と断定するべき脆弱性ではありません。(myF5)

ただし、ワーカーの異常終了や再起動が繰り返されれば、利用者側では一時的な接続切断、HTTP 502・503エラー、レスポンス遅延として現れる可能性があります。

Azure Linux 3.0のNGINXが影響を受けるか確認する

OSとRPMパッケージのバージョンを確認する

最初に、対象サーバーがAzure Linux 3.0であることを確認します。

cat /etc/os-release

続いて、インストールされているNGINXパッケージを確認します。

rpm -q nginx

バージョン、リリース番号、CPUアーキテクチャを明確に表示するには、次のコマンドが便利です。

rpm -q nginx --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n'

脆弱なパッケージでは、次のような結果になります。

nginx-1.28.3-6.azl3.x86_64

修正版では、アーキテクチャに応じて次のように表示されます。

nginx-1.28.3-8.azl3.x86_64

nginx-1.28.3-8.azl3.aarch64

MicrosoftのAzure Linux 3.0パッケージリポジトリには、2026年7月22日付で両アーキテクチャ向けの1.28.3-8が掲載されています。(Microsoft Packages)

バージョンの判断基準は次のとおりです。

確認結果	判断と対応
`1.28.3-6.azl3`	影響対象。速やかに更新する
`1.28.3-7.azl3`	修正版に到達していないため、`1.28.3-8`以上へ更新する
`1.28.3-8.azl3`以上	このCVEに対する修正版パッケージ
`rpm -q nginx`で未インストールと表示	コンテナ、ソースビルド、別ベンダーのパッケージを確認する
Azure Linux以外のパッケージ	使用しているディストリビューションやNGINX提供元の情報を確認する

`nginx -v`だけでは判定しない

次のコマンドは、NGINX本体のバージョン確認には利用できます。

nginx -v

ただし、表示結果は次のようになり、Azure Linux側のパッケージリリース番号である-6.azl3や-8.azl3が分からないことがあります。

nginx version: nginx/1.28.3

したがって、CVE-2026-56434への対応確認では、nginx -vではなくrpm -q nginxの結果を証跡として残してください。

SSI関連の設定を確認する

有効な設定全体から関連ディレクティブを検索します。

sudo nginx -T 2>&1 | grep -nE 'ssi[[:space:]]+on;|proxy_pass|proxy_buffering[[:space:]]+off;'

特に確認するのは次の記述です。

location /content/ {
    ssi on;

    proxy_pass http://backend;
    proxy_buffering off;
}

このように、同じlocationで3つの設定が組み合わされている場合は、公開されている発生条件に近い構成です。

検索結果に各ディレクティブが表示されても、それぞれが別の仮想ホストや別のURLに設定されていることがあります。行の一致だけで判断せず、nginx -Tの出力から前後のhttp、server、locationブロックを確認してください。

また、ssi on;が上位のhttpまたはserverコンテキストで設定され、下位のlocationへ継承されている可能性にも注意が必要です。

NGINXを1.28.3-8へ更新する手順

設定ファイルをバックアップする

更新前にNGINXの設定ディレクトリを保存します。

sudo cp -a /etc/nginx "/etc/nginx.backup-$(date +%Y%m%d-%H%M%S)"

現在のパッケージ情報も記録しておくと、更新証跡として利用できます。

rpm -q nginx --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n'

更新前に設定テストを実行する

パッケージ更新前の時点で設定エラーがないことを確認します。

sudo nginx -t

成功時は、構文が正常であることを示すメッセージが表示されます。

syntax is ok
test is successful

ここで失敗する場合は、更新前から設定に問題が存在します。先に設定エラーを解消し、正常な状態を確保してからパッケージを更新してください。

tdnfで利用可能なパッケージを確認する

Azure Linux 3.0では、パッケージ管理にtdnfを使用します。利用可能なNGINXパッケージを確認します。

sudo tdnf list nginx

候補として1.28.3-8.azl3以上が表示されることを確認したら、更新を実行します。

sudo tdnf update nginx

tdnf updateは、Azure Linuxでパッケージを更新する標準的な操作です。依存するNGINX関連パッケージがある場合は、トランザクション内容を確認してから実行してください。(Microsoft Learn)

更新後のRPMバージョンを確認する

更新完了後、再びパッケージのリリース番号を確認します。

rpm -q nginx --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n'

少なくとも次のいずれか、またはそれより新しいリリースになっていることを確認します。

nginx-1.28.3-8.azl3.x86_64

nginx-1.28.3-8.azl3.aarch64

設定を再確認してNGINXを再起動する

更新後にも設定テストを実行します。

sudo nginx -t

問題がなければ、NGINXを再起動します。

sudo systemctl restart nginx

パッケージを更新しただけでは、更新前のNGINXプロセスがメモリ上で動作し続ける場合があります。また、通常の設定リロードではマスタープロセスの実行バイナリが置き換わらないため、セキュリティ更新の完了確認では明示的な再起動が確実です。

サービスの状態を確認します。

sudo systemctl is-active nginx

詳細を確認する場合は、次のコマンドを使用します。

sudo systemctl --no-pager --full status nginx

直近のログも確認してください。

sudo journalctl -u nginx --since "10 minutes ago" --no-pager

外部または監視ネットワークから、実際のURLへアクセスして確認することも重要です。

curl -fsS https://example.com/health >/dev/null && echo "health check: OK"

example.comの部分は、対象サービスのヘルスチェックURLに置き換えてください。

複数台構成ではローリング更新を行う

ロードバランサー配下に複数のNGINXサーバーがある場合、一斉再起動は避けます。次の順番で1台ずつ更新すると、サービス停止のリスクを抑えられます。

対象ノードをロードバランサーから切り離す
nginx -tで更新前の状態を確認する
tdnf update nginxを実行する
RPMパッケージが1.28.3-8.azl3以上であることを確認する
NGINXを再起動する
ヘルスチェックとログを確認する
ノードをロードバランサーへ戻す
次のノードで同じ作業を行う

すべてのノードを更新し終えるまで、対応完了とは判断しないでください。古いノードが1台でも残っていれば、リクエストの一部が脆弱な環境へ振り分けられます。

1.28.3-8へ更新できない場合の切り分け

リポジトリに古いバージョンしか表示されない

tdnf list nginxで1.28.3-6や1.28.3-7しか表示されない場合は、パッケージメタデータや利用中のミラーを確認します。

sudo tdnf clean all
sudo tdnf list nginx

改善しない場合は、次の点を確認してください。

組織内のミラーリポジトリが最新状態へ同期されているか
Azure Linux 3.0の正しいリポジトリが有効になっているか
NGINXパッケージがバージョン固定されていないか
プロキシやファイアウォールがリポジトリへの通信を遮断していないか
更新管理ツール側で承認待ちになっていないか

インターネット上で見つけたRPMを出所確認なしに直接インストールする方法は避けてください。組織で承認されたリポジトリ、ミラー、更新管理経路から配布するのが安全です。

RPMではなくコンテナ内でNGINXを動かしている

ホストOSで次のように表示されても、NGINXコンテナが存在しないとは限りません。

package nginx is not installed

Dockerコンテナ内のパッケージを確認する例は次のとおりです。

docker exec <container-name> rpm -q nginx

Kubernetesの場合は、対象Pod内で確認します。

kubectl exec <pod-name> -- rpm -q nginx

コンテナ環境では、稼働中のコンテナだけを手作業で更新するのではなく、修正版パッケージを含むベースイメージからイメージを再ビルドし、新しいイメージへ入れ替えることが基本です。ホスト側のNGINXを更新しても、コンテナ内のNGINXには反映されません。

ソースビルドや別リポジトリのNGINXを使用している

nginxコマンドが存在するのにrpm -q nginxでパッケージが見つからない場合は、実行ファイルの場所を確認します。

command -v nginx

RPMが管理しているファイルかどうかも確認できます。

rpm -qf "$(command -v nginx)"

「ファイルを所有するパッケージがない」と表示された場合は、ソースビルドや手動配置の可能性があります。その場合、Azure Linuxの1.28.3-8.azl3という修正版情報をそのまま適用することはできません。ビルド元、導入手順、NGINX提供元を特定し、その提供元が示す修正版へ更新してください。

すぐに更新できない場合の一時的な露出低減

MSRCの掲載内容では、CVE-2026-56434に対する個別の回避策は示されていません。そのため、設定変更だけで対応完了とするのではなく、修正版への更新計画を優先してください。(Microsoft Security Response Center)

業務上の理由ですぐに更新できない場合は、公式回避策ではなく一時的な露出低減策として、次の対応を検討できます。

SSIが不要なURLではssi on;を削除または無効化する
アプリケーションが許容する場合はproxy_buffering off;を見直す
上流サーバーとの通信経路を信頼できるネットワークに限定する
上流通信にTLSを使用している場合は、証明書検証を適切に構成する
WAFやアクセス制御だけに依存せず、異常なワーカー再起動を監視する

proxy_bufferingを有効にすると、Server-Sent Events、ストリーミング応答、逐次出力、低遅延配信などの挙動が変わる可能性があります。本番環境で直接変更せず、検証環境でレスポンス時間やアプリケーション動作を確認してください。

対応時に失敗しやすいポイント

失敗しやすい対応	問題点	正しい対応
`nginx -v`だけで確認する	`-6.azl3`と`-8.azl3`を区別できない	`rpm -q nginx`でリリース番号まで確認する
設定検索で3項目が見つかっただけで影響ありと判断する	別々の仮想ホストに設定されている可能性がある	同じリクエスト処理経路か確認する
パッケージ更新後に再起動しない	古いプロセスが動作し続ける可能性がある	`nginx -t`後に`systemctl restart nginx`を実行する
設定リロードだけで完了とする	マスタープロセスの実行バイナリが更新されない	セキュリティ更新後は再起動する
ホストOSだけを確認する	コンテナ内のNGINXを見落とす	実際に通信を処理するコンテナやPodも確認する
1台だけ更新する	未更新ノードへ通信が振り分けられる	全ノードを台帳化してローリング更新する
外部スキャン結果だけで判断する	バナーでは`1.28.3`までしか分からず、誤検知する場合がある	RPM情報と更新履歴を証跡として保存する
設定テストなしで再起動する	設定エラーによってNGINXが起動しなくなる	更新前後に`nginx -t`を実行する

対応完了の判断基準

CVE-2026-56434への対応は、パッケージのインストールだけで終わりではありません。次の条件をすべて満たしていることを確認します。

Azure Linux 3.0上のNGINXをすべて洗い出している
VM、物理サーバー、コンテナ、Kubernetes Podを確認している
RPMパッケージが1.28.3-8.azl3以上になっている
更新後にnginx -tが成功している
NGINXを再起動している
サービスが正常に起動している
ヘルスチェックが成功している
エラーログに新たな異常がない
ロードバランサー配下の全ノードを更新している
パッケージバージョンと作業日時を更新証跡として保存している

最初に実施すべき作業は、対象環境でrpm -q nginxを実行し、1.28.3-6.azl3が残っていないかを確認することです。該当する場合は、設定条件の調査だけで対応を止めず、1.28.3-8.azl3以上への更新、設定テスト、NGINX再起動、稼働確認までを一連の作業として実施してください。

この記事を書いた人

佐藤健司

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

CVE-2026-56434対策｜Azure Linux 3.0のNGINXを1.28.3-8へ更新する手順

CVE-2026-56434で最初に確認すべきこと

脆弱性が成立する構成と想定される影響

SSIとリバースプロキシを組み合わせた構成が対象

use-after-freeとは何か

Azure Linux 3.0のNGINXが影響を受けるか確認する

OSとRPMパッケージのバージョンを確認する

`nginx -v`だけでは判定しない

SSI関連の設定を確認する

NGINXを1.28.3-8へ更新する手順

設定ファイルをバックアップする

更新前に設定テストを実行する

tdnfで利用可能なパッケージを確認する

更新後のRPMバージョンを確認する

設定を再確認してNGINXを再起動する

複数台構成ではローリング更新を行う

1.28.3-8へ更新できない場合の切り分け

リポジトリに古いバージョンしか表示されない

RPMではなくコンテナ内でNGINXを動かしている

ソースビルドや別リポジトリのNGINXを使用している

すぐに更新できない場合の一時的な露出低減

対応時に失敗しやすいポイント

対応完了の判断基準

この記事を書いた人

コメント

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

CVE-2026-56434対策｜Azure Linux 3.0のNGINXを1.28.3-8へ更新する手順

CVE-2026-56434で最初に確認すべきこと

脆弱性が成立する構成と想定される影響

SSIとリバースプロキシを組み合わせた構成が対象

use-after-freeとは何か

Azure Linux 3.0のNGINXが影響を受けるか確認する

OSとRPMパッケージのバージョンを確認する

nginx -vだけでは判定しない

SSI関連の設定を確認する

NGINXを1.28.3-8へ更新する手順

設定ファイルをバックアップする

更新前に設定テストを実行する

tdnfで利用可能なパッケージを確認する

更新後のRPMバージョンを確認する

設定を再確認してNGINXを再起動する

複数台構成ではローリング更新を行う

1.28.3-8へ更新できない場合の切り分け

リポジトリに古いバージョンしか表示されない

RPMではなくコンテナ内でNGINXを動かしている

ソースビルドや別リポジトリのNGINXを使用している

すぐに更新できない場合の一時的な露出低減

対応時に失敗しやすいポイント

対応完了の判断基準

この記事を書いた人

関連記事

コメント

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

`nginx -v`だけでは判定しない

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