MENU

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

Linux

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)

確認項目内容
対象OSAzure 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台ずつ更新すると、サービス停止のリスクを抑えられます。

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

すべてのノードを更新し終えるまで、対応完了とは判断しないでください。古いノードが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再起動、稼働確認までを一連の作業として実施してください。

Linux
Nginx SSI 脆弱性対策 Azure Linux CVE-2026-56434

この記事を書いた人

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

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

関連記事

コメント

コメントする

目次