nginxに遠隔で狙える欠陥5件、Ubuntuは全LTSに修正

やること

nginx（Web サーバーのソフト）を修正版へ更新してください。

• 公式の配布物は 1.31.7 以降（開発版）、1.30.6 以降（安定版）です
• Ubuntu は apt で更新してください。USN-8955-1（10月26日）と USN-8955-2（11月5日）が出ています。20.04 LTS 以前は Ubuntu Pro が必要です

Ubuntu は公式の新しいバージョンへ上げず、今のバージョンに修正だけを取り込みます。これをバックポートといいます。たとえば 24.04 LTS は 1.24.0 のままです。バージョン番号だけでは判断できないので、パッケージのバージョンを上の表と比べてください。同じ仕組みの例は Apache httpdに20件の脆弱性、最大CVSS 9.8で更新を にもあります。

USN-8955-1 と USN-8955-2 のページには、再起動についての記載がありません。通常のシステム更新で必要な変更は入ると書かれています。nginx は動いているプロセスが古いプログラムを持ち続けるので、更新のあとは nginx を再起動し、nginx -V や設定の検査で動作を確かめてください。

nginx の1.31.8（10月21日）には、セキュリティの修正が入っていません。10月14日の 1.31.7 の修正が、そのまま最新です。

公式の一覧とリリースノートには、回避策が書かれていません。F5 の案内に詳細があります。

何が危ないのか

nginx は10月14日に5件を修正しました。公式の深刻度はどれも Medium ですが、CVE-2026-93479 の CVSS は v3.1 で 8.1、v4.0 で 9.2 です。Ubuntu の優先度は Medium です。

当たる条件は、それぞれ特定の設定です。oss-security の投稿は、影響を「受けるように見える」という推定の形で書いています。

• CVE-2026-93479：map の正規表現のキャプチャ変数を、root かアクセスログの書式が、map の出力より前に参照する設定で、ワーカー（処理を担うプロセス）のメモリが壊れます。ログインは要りません。条件によっては、キャッシュされない変数を文字列の式で使う場合でも起きます
• CVE-2026-15176：alias と rewrite を組み合わせた場所で、$request_filename を set や return で参照するか、アクセスログの書式で使う設定です
• CVE-2026-97205：AIO（非同期のファイル入出力）を有効にし、SSI のページで include virtual を処理する設定です
• CVE-2026-97629：共有のセッションキャッシュを使い、ssl_session_ticket_key を明示しない設定で、TLS のセッションが偽造され、クライアント証明書の確認を回避されるおそれがあります
• CVE-2026-95101：HTTP/3 を使い、proxy_request_buffering が on の設定で、転送先への要求にデータを混ぜられるおそれがあります

ワーカーの再起動を招くのは、CVE-2026-93479、CVE-2026-15176、CVE-2026-97205 です。ASLR（メモリ配置の無作為化）が無効か回避された場合は、コードの実行につながるおそれがあります。 oss-security の投稿と Ubuntu のページは、CVE-2026-93479 と CVE-2026-95101 を、管理の機能（コントロールプレーン）ではなく、通信を処理する側（データプレーン）だけの問題としています。悪用の確認は公表されていません。

対象

どれも特定の設定や機能を使う場合に当たります。公式の一覧では、版の範囲が CVE ごとに違います。

• CVE-2026-15176：0.1.29 から 1.31.6
• CVE-2026-93479：1.31.2 から 1.31.6、1.30.0 から 1.30.5
• CVE-2026-95101：1.25.0 から 1.31.6
• CVE-2026-97629：1.23.2 から 1.31.6
• CVE-2026-97205：0.8.11 から 1.31.6

Ubuntu では、CVE-2026-95101 は 26.04 LTS と 26.10、CVE-2026-97629 は 24.04 LTS 以降が対象です。USN-8955-2 は、20.04 LTS 以前の対応で、CVE-2026-42533（map の処理）も同じ更新で直ります。

中小企業が学べること

nginx の設定ファイルは、年月がたつと、誰が何のために書いたかが分からなくなります。今回のように、特定の設定の組み合わせで当たる欠陥は、自社の設定にその組み合わせがあるかどうかで、急ぐ度合いが決まります。設定を、次のように調べてください。

• grep -rn "map " /etc/nginx で、正規表現を使う map があるか。あれば root や log_format との組み合わせを見る
• grep -rn "alias\|aio\|ssi\|http3\|ssl_session_cache" /etc/nginx で、今回の条件に出てくる設定を使っているか

使っていない場合も、更新は同じように必要です。設定の確認は、急ぐ順番を決めるためで、更新を省く理由にはなりません。

設定の変更を履歴に残しておくと、半年後に「この alias は何のためか」を調べられます。更新のたびに、設定のうち使っていないものを消す日を決めてください。