Azure Linux 3.0のCVE-2026-42533対策｜NGINX 1.28.3-8へ更新

Azure Linux 3.0でazl3版のNGINXパッケージ1.28.3-6を使用している場合、CVE-2026-42533への基本対応は1.28.3-8以上へ更新することです。MSRCは修正版として1.28.3-8を示しており、個別の回避策は掲載していません。設定変更やWAFだけで済ませず、Azure Linuxの公式リポジトリから修正版を適用してください。上流のNGINXでは1.30.4と1.31.3で修正されていますが、Azure Linuxでは上流バージョンが1.28.3のままRPMのRelease番号に修正が反映されます。(msrc.microsoft.com)

この脆弱性は、すべてのNGINX環境で直ちに悪用できるものではありません。mapディレクティブで正規表現を使用し、正規表現のキャプチャ変数や非キャッシュ変数が特定の順序で評価される構成が前提です。ただし、条件を満たす環境では、認証されていない攻撃者が細工したHTTPリクエストを送ることで、NGINXワーカープロセスのヒープバッファオーバーフローを引き起こす可能性があります。結果としてサービス拒否が発生し、ASLRが無効または回避された環境ではコード実行につながる可能性もあります。(NVD)

CVE-2026-42533とは

CVE-2026-42533は、NGINX Open SourceおよびNGINX Plusのmapディレクティブと正規表現処理に関係する、ヒープベースのバッファオーバーフロー脆弱性です。

項目	内容
CVE番号	CVE-2026-42533
公開日	2026年7月15日
脆弱性の種類	ヒープベースのバッファオーバーフロー
CWE	CWE-122
CVSS v4.0	9.2／Critical
NGINX公式の深刻度	Major
攻撃経路	ネットワーク経由の細工されたHTTPリクエスト
必要な権限	不要
主な影響	ワーカープロセスの再起動、サービス拒否、限定的な条件下でのコード実行
上流NGINXの影響範囲	0.9.6～1.31.2
上流NGINXの修正版	1.30.4以降、1.31.3以降
Azure Linux 3.0の対象パッケージ	azl3 nginx 1.28.3-6
Azure Linux 3.0の修正版	azl3 nginx 1.28.3-8
MSRCの個別回避策	掲載なし

CVSS v4.0では9.2の「Critical」と評価されていますが、NGINX公式のセキュリティ情報では「Major」と分類されています。これは評価基準の違いによるもので、情報が矛盾しているわけではありません。攻撃成立には特定の設定条件が必要である一方、ネットワーク経由かつ認証不要であり、成立した場合の影響が大きいことがCVSSに反映されています。(NVD)

mapディレクティブと正規表現で何が起きるのか

NGINXのmapディレクティブは、URI、HTTPヘッダー、クエリパラメーターなどの値を条件として、別の変数へ値を割り当てる機能です。

例えば、次のような用途で使われます。

• URIに応じて転送先を切り替える
• 特定のUser-Agentを判定する
• HTTPヘッダーからキャッシュ可否を決める
• アクセスログに出力する区分を生成する
• リクエスト条件に応じてレート制限のキーを変える

mapブロックでは、~で始まる条件が大文字・小文字を区別する正規表現、~*で始まる条件が大文字・小文字を区別しない正規表現です。正規表現に含まれるキャプチャは、$1や$2などの位置キャプチャ、または名前付き変数として、別のディレクティブから参照できます。

また、mapブロック内のvolatileは、生成した変数をキャッシュしないようにする指定です。(Nginx)

CVE-2026-42533では、主に次の処理順序が問題になります。

1. リクエスト由来の値をmapの正規表現で照合する
2. 正規表現によってキャプチャ変数が生成される
3. 別の文字列式で、mapの出力変数より先にキャプチャ変数を参照する
4. 特定の条件でメモリ処理が不正になり、ヒープバッファオーバーフローが発生する

非キャッシュ変数を含む文字列式でも、一定の条件下で同様の問題が発生する可能性があります。重要なのは、単にmapを使っているだけではなく、正規表現、キャプチャ変数、変数の評価順序が組み合わさることです。(NVD)

Azure Linux 3.0が影響を受けるか確認する方法

OSがAzure Linux 3.0か確認する

最初に、対象サーバーのOSを確認します。

cat /etc/os-release

出力のNAME、VERSION、VERSION_IDなどを確認し、Azure Linux 3.0の環境であることを特定します。

複数台を運用している場合は、ロードバランサー配下の全ノードだけでなく、次の対象も確認してください。

• 停止中のVM
• スケールアウト用のイメージ
• VMテンプレート
• 開発環境と検証環境
• コンテナイメージ
• 障害復旧用の待機系
• 自動構築に使うPackerやDockerfile

稼働中の1台だけを更新しても、古いテンプレートから再作成された際に1.28.3-6が復活する可能性があります。

NGINXのRPMバージョンを確認する

Azure Linux 3.0では、次のコマンドでNGINXパッケージのVersion-Releaseを確認します。

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

判定の目安は次のとおりです。

確認結果	判定
1.28.3-6相当	CVE-2026-42533の影響対象
1.28.3-8相当以上	MSRCが示す修正版
1.28.3-8未満	修正版とは判断せず、更新を確認
nginxがインストールされていない	ホスト上のRPMは対象外。コンテナ内も別途確認
Azure Linux以外のリポジトリから導入	そのパッケージ提供元の修正情報を確認
ソースコードから独自ビルド	適用済みパッチとビルド内容を個別に確認

ここで注意したいのが、次のコマンドだけでは判定できない点です。

nginx -v

nginx -vでは、更新前も更新後もnginx/1.28.3と表示される可能性があります。Azure Linuxの修正有無を区別するには、上流バージョンだけでなく、RPMのRelease番号である-6や-8まで確認する必要があります。

NGINXがどのリポジトリから導入されたか確認する

Azure Linux公式パッケージ以外のNGINXを使用している場合、MSRCが示す1.28.3-8をそのまま判定基準にはできません。

次のコマンドでパッケージ情報を確認します。

rpm -qi nginx

確認する項目は次のとおりです。

• Version
• Release
• Vendor
• Packager
• Build Date
• Install Date

NGINX公式リポジトリ、社内リポジトリ、独自ビルドを混在させている環境では、同じ1.28.3でもパッチ内容が異なる可能性があります。

mapと正規表現を使用しているか調査する

設定上の悪用条件を確認するには、includeされたファイルを含む有効な設定全体を出力します。

sudo nginx -T > /tmp/nginx-full-config.txt 2>&1

続いて、mapディレクティブを検索します。

grep -nE '^[[:space:]]*map[[:space:]]' /tmp/nginx-full-config.txt

正規表現、位置キャプチャ、volatileの使用箇所も確認します。

grep -nE '^[[:space:]]*~\*?|volatile;|\$[1-9][0-9]*' /tmp/nginx-full-config.txt

この検索だけで脆弱性の成立を断定することはできません。該当箇所が見つかったら、次の観点で設定を追跡します。

確認項目	優先して調べる内容
mapの入力変数	$uri、$request_uri、$arg_*、$http_*など外部入力の影響を受けるか
正規表現	~または~*から始まる条件があるか
キャプチャ	$1、$2、名前付きキャプチャを別のディレクティブで利用しているか
評価順序	文字列の中でキャプチャ変数がmapの出力変数より先に記述されていないか
非キャッシュ変数	volatile;を指定したmapがあるか
利用先	set、return、proxy_pass、proxy_set_header、ログ設定などで連結していないか
外部公開	インターネットや信頼できないネットワークからリクエストを受けるか

nginx -Tの出力には、内部ホスト名、転送先、認証用ヘッダー、トークン、証明書のパスなどが含まれることがあります。調査ファイルをチケットやチャットへそのまま添付せず、アクセス権を制限し、調査終了後は適切に削除してください。

設定上の条件が見つからなくても、修正版への更新は必要です。現在は該当設定がなくても、将来の設定変更や自動生成された設定によって条件が成立する可能性があるためです。

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

更新前に設定と正常性を確認する

更新前に設定構文を確認します。

sudo nginx -t

続いて、設定ファイルをバックアップします。

sudo tar -C / -czf /root/nginx-config-$(date +%Y%m%d%H%M%S).tar.gz etc/nginx

更新前の状態として、最低限次の情報も記録しておくと切り戻し判断がしやすくなります。

rpm -q nginx
sudo systemctl --no-pager --full status nginx
sudo nginx -T > /root/nginx-config-before-update.txt 2>&1

負荷分散された複数台構成では、最初に1台だけをロードバランサーから外し、カナリア更新を行います。単一サーバーの場合は、再起動による短時間の通信影響を考慮してメンテナンス時間を確保してください。

tdnfで修正版へ更新する

Azure Linux 3.0では、パッケージ管理にtdnfを使用します。パッケージを指定したtdnf upgradeでは、リポジトリから解決可能な新しいバージョンへ更新できます。(Microsoft Learn)

最初に、リポジトリ上のNGINX情報を確認します。

sudo tdnf info nginx

候補に1.28.3-8相当以上が表示されることを確認したうえで、更新します。

sudo tdnf upgrade nginx --refresh

リポジトリ情報が古く、修正版が表示されない場合は、キャッシュを更新します。

sudo tdnf clean all
sudo tdnf makecache
sudo tdnf info nginx

それでも1.28.3-6しか表示されない場合は、次の原因を確認してください。

• 社内ミラーへの同期が完了していない
• 更新用リポジトリが無効になっている
• 特定バージョンへ固定されている
• プロキシやDNSの問題でリポジトリへ接続できない
• Azure Linux公式以外のリポジトリが優先されている

有効なリポジトリは次のコマンドで確認できます。

sudo tdnf repolist

修正版が見つからないことを理由に、出所不明のRPMを直接ダウンロードして導入するのは避けてください。依存関係や署名検証、今後の更新経路に問題が生じる可能性があります。

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

更新完了後、再度RPMのVersion-Releaseを確認します。

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

1.28.3-8相当以上になっていることを確認してください。

nginx -vが引き続き1.28.3と表示されても、直ちに更新失敗とは限りません。CVE-2026-42533のAzure Linux向け修正判定では、RPMのRelease番号が重要です。

設定テスト後にNGINXを再起動する

パッケージ更新後に設定構文をテストします。

sudo nginx -t

標準のsystemdサービス名がnginxの場合は、次のように再起動します。

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

パッケージを更新した後、nginx -s reloadだけで完了扱いにしないことが重要です。

通常の設定リロードは、実行中のマスタープロセスに設定を再読み込みさせる操作です。新しい実行ファイルへ切り替える操作とは異なります。NGINX公式ドキュメントでも、HUPは設定変更、USR2は実行ファイルのアップグレードとして区別されています。一般的なsystemd運用ではサービスを再起動し、停止を許容できない環境では、検証済みのローリング更新またはNGINXのライブバイナリアップグード手順を使用します。(Nginx)

疎通とログを確認する

再起動後は、実際のサービスURLで確認します。

curl -fsS https://example.com/health

併せて、直近のサービスログを確認します。

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

次の項目を確認してください。

• NGINXがActive状態になっている
• HTTPおよびHTTPSの疎通が成功する
• TLS証明書が正しく提示される
• リバースプロキシ先へ接続できる
• mapによる振り分け結果が更新前と変わっていない
• 502、503、504などのエラーが増えていない
• ワーカープロセスが繰り返し終了していない
• レスポンスタイムが急増していない

構成別に必要な対応を判断する

Azure Linuxホストを更新すれば、すべてのNGINXが修正されるとは限りません。NGINXがどこにインストールされているかを区別する必要があります。

構成	必要な対応
Azure Linux VM上のRPMとして稼働	ホストのnginxを1.28.3-8以上へ更新し、プロセスを再起動
複数VMのロードバランサー構成	1台ずつ切り離し、更新、再起動、ヘルスチェック、復帰を繰り返す
Azure Linuxベースのコンテナ	コンテナイメージ内のNGINXを更新し、イメージを再ビルドして再配置
DebianやAlpineベースのNGINXコンテナ	Azure Linuxホストではなく、コンテナイメージ提供元の修正版へ更新
AKSノード上のIngress Controller	ノードOSのRPMではなく、Ingress Controllerのコンテナイメージを確認
ゴールデンイメージからVMを展開	稼働中VMに加えて、元となるイメージと構築処理も修正
ソースコードから独自ビルド	上流パッチの適用状況を確認し、再ビルドと再配置を実施

コンテナ環境では、ホスト上で次のように表示されても安全とは断定できません。

package nginx is not installed

これはホストOSにNGINXのRPMがないことを示すだけです。実際のNGINXがコンテナ内で動いている場合は、コンテナイメージのパッケージ、SBOM、Dockerfile、イメージスキャン結果を確認してください。

修正版をすぐ適用できない場合の一時対策

MSRCはCVE-2026-42533に対する個別の回避策を掲載していません。そのため、以下は修正の代替ではなく、更新までの露出を減らすための一時的な補完策です。(msrc.microsoft.com)

外部からの到達範囲を制限する

インターネット公開が不要な管理画面やAPIは、ロードバランサー、ファイアウォール、ネットワークセキュリティ設定などでアクセス元を制限します。

ただし、公開Webサイトのように外部通信を遮断できない環境では、この方法だけで十分な対策にはなりません。

不要なmapと正規表現を一時的に無効化する

業務上使用していないmap、正規表現、volatile指定がある場合は、影響を検証したうえで削除または単純な条件へ置き換えることを検討します。

ただし、mapはルーティング、認証、キャッシュ、アクセス制御などに使われていることがあります。内容を確認せず一括で無効化すると、別のセキュリティ問題やサービス障害を引き起こす可能性があります。

WAFやレート制限を補助的に利用する

WAF、リクエストサイズ制限、レート制限は、大量の試行や異常なリクエストを減らす補助策になります。

一方、CVE-2026-42533はNGINX設定と変数の評価順序に依存します。すべての環境に共通する単一の攻撃文字列が前提ではないため、一般的なWAFルールだけで完全に防げるとは限りません。

監視を強化する

修正版を適用するまで、次の兆候を監視します。

• NGINXワーカープロセスの異常終了
• 短時間に繰り返されるプロセス再生成
• 502や接続リセットの増加
• カーネルログ上のsegfault
• 原因不明のCPUまたはメモリ使用量増加
• 特定URIやヘッダーに集中した不審なリクエスト

確認例は次のとおりです。

sudo journalctl -u nginx --since "24 hours ago" --no-pager
sudo journalctl -k --since "24 hours ago" --no-pager | grep -Ei 'nginx|segfault|killed|oom'

これらのログが見つかっただけで、CVE-2026-42533が悪用されたとは断定できません。設定不備、メモリ不足、別の不具合でも似た事象が発生します。アクセスログ、エラーログ、プロセス履歴、監視データを時刻で突き合わせて判断してください。

更新時に失敗しやすいポイント

失敗例	問題点	正しい対応
nginx -vだけを確認する	RPMの-6と-8を区別できない	rpm -qでVersion-Releaseを確認
パッケージ更新後にreloadだけ行う	実行中の旧バイナリが残る可能性がある	再起動または検証済みのバイナリ更新手順を実施
稼働中の1台だけ更新する	スケールアウトや再構築で脆弱版が復活する	テンプレート、イメージ、構築コードも更新
ホストだけを確認する	コンテナ内のNGINXを見落とす	実際にNGINXが入っているイメージを確認
mapを使っていないため更新を延期する	将来の設定変更や見落としに対応できない	設定条件にかかわらず修正版へ更新
社内ミラーの古いパッケージを最新と判断する	1.28.3-8がまだ同期されていない可能性がある	リポジトリ同期状況と候補バージョンを確認
上流の1.30.4を無計画に直接導入する	Azure Linuxの依存関係やサポート経路が変わる	Azure Linux公式の1.28.3-8を優先
WAFを入れたため修正不要と判断する	設定依存の脆弱性を完全には遮断できない	WAFは補助策とし、パッケージを更新

悪用が疑われる場合は更新だけで終わらせない

ワーカープロセスの異常終了に加えて、次のような兆候が確認された場合は、単なる障害対応ではなくセキュリティインシデントとして扱います。

• NGINX実行ユーザーによる不審なプロセス
• 覚えのないファイルや実行可能ファイルの作成
• 通常とは異なる外部IPアドレスへの通信
• Webルートや設定ファイルの改変
• 認証情報や秘密情報への不審なアクセス
• 更新後も続く異常なプロセス起動

CVE-2026-42533では、ASLRが無効、または攻撃者がASLRを回避できる場合にコード実行へつながる可能性が示されています。侵害が疑われるホストでは、パッケージ更新だけで安全になったと判断せず、ログと証拠を保全し、ネットワークから隔離したうえで、修正版を含む信頼できるイメージからの再構築を検討してください。(NVD)

よくある疑問

nginx -vが1.28.3のままでも修正済みですか

Azure Linux 3.0では、修正前の1.28.3-6と修正後の1.28.3-8で、上流バージョン部分が同じです。

次のコマンドでRPMのRelease番号まで確認してください。

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

1.28.3-8相当以上であれば、MSRCが示す修正版です。

mapを使っていなければ更新しなくてもよいですか

既知の攻撃条件にはmapと正規表現などが関係するため、現在の悪用可能性を評価する材料にはなります。

ただし、ソフトウェア自体が影響対象であることは変わりません。設定の見落とし、将来の変更、別ファイルからのincludeも考慮し、修正版へ更新するのが安全です。

Azure LinuxでもNGINX 1.30.4へ上げる必要がありますか

Azure Linux 3.0では、MSRCが修正版として示す1.28.3-8を適用します。

上流NGINXの修正版が1.30.4または1.31.3であっても、Azure Linux向けパッケージでは修正が1.28.3系列へ取り込まれています。Azure Linux公式パッケージから上流版へ切り替える場合は、機能差、依存関係、更新方法、サポート範囲を別途検証する必要があります。(Nginx)

サービスの再起動は必要ですか

新しい実行ファイルを稼働プロセスへ反映する必要があります。

単一サーバーでは設定テスト後にsystemctl restart nginxを実施し、複数台構成では1台ずつ更新するローリング方式が現実的です。停止を許容できない特殊な環境では、NGINX公式のライブバイナリアップグレード手順を十分に検証したうえで利用します。(Nginx)

まずRPMのRelease番号を確認する

CVE-2026-42533への対応では、次の順序で進めると判断を誤りにくくなります。

1. cat /etc/os-releaseでAzure Linux 3.0か確認する
2. rpm -qでNGINXのVersion-Releaseを確認する
3. 1.28.3-6であれば、tdnfで1.28.3-8以上へ更新する
4. nginx -tを実行してから、再起動またはローリング更新を行う
5. 疎通、ログ、ワーカープロセスの状態を確認する
6. コンテナ、ゴールデンイメージ、自動構築処理も更新する

設定上の攻撃条件があるかどうかは、緊急度や露出を判断するために確認します。しかし、正式な修正はパッケージ更新です。まず次のコマンドを実行し、1.28.3-6が残っていないか確認してください。

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