nginxの脆弱性5件 Ubuntuの修正版と自社の設定の確かめ方

Webサイトや業務システムの前段にnginxを置いているサーバーで、「今回の脆弱性はうちに関係あるのか」をすぐに答えられないことがあります。今回取り上げる5件は、どれも特定のディレクティブを組み合わせたときに起きるもので、パッケージを更新したかどうかと、設定が条件に当たるかどうかを分けて確かめる必要があるためです。

Ubuntuは2026年10月26日、nginxの脆弱性5件を修正するセキュリティ通知「USN-8955-1」を公開しました。対象は Ubuntu 26.10、26.04 LTS、24.04 LTS、22.04 LTS です。この記事では、Ubuntuの通知とCVEごとのページをもとに、5件の条件を設定の単位で整理し、編集部の検証環境（Ubuntu 24.04）で修正版を入れて確かめた手順を示します。

5件は、関係する設定がそれぞれ違う

UbuntuのCVEのページは、5件の説明と、Ubuntuのリリースごとの対応状況を載せています。条件になる設定を中心にまとめると、次のとおりです。

CVE-2026-95101 はHTTP/3の機能（1.25.0で追加）に関するもので、Ubuntuでは26.04 LTSと26.10だけが対象です。CVE-2026-97629 は1.23.2で入った変更に由来し、22.04 LTSは対象外とされています。

深刻度の表示は、資料によって差があります。UbuntuのCVEのページでは、CVE-2026-15176・93479・97205 が CVSS v4.0 で 9.2（Critical）、v3 で 8.1（High）と示されています。一方、Ubuntu自身の優先度（Ubuntu priority）は5件とも Medium で、開発元のnginx.orgの告知も5件の深刻度をいずれも medium としています。いずれも、特定の設定がある場合に限られる問題のため、自社の設定に当てはまるかどうかで緊急度が変わります。

修正版のパッケージと、nginx -v では見分けられない点

USN-8955-1 が示す修正版は次のとおりです。

• 26.10：nginx 1.30.4-7ubuntu1.1
• 26.04 LTS：nginx 1.28.3-2ubuntu1.12
• 24.04 LTS：nginx 1.24.0-2ubuntu7.19
• 22.04 LTS：nginx 1.18.0-6ubuntu14.22

nginx-core、nginx-full、nginx-light、nginx-extras の各パッケージも同じ版です。通知は「通常のシステムの更新で必要な変更がすべて行われる」としています。

Ubuntuのパッケージではなく、nginx.orgのパッケージや自分でビルドしたnginxを使っている場合は、本家の修正版で判断します。nginx.orgのセキュリティ告知によると、5件は2026年10月14日に出たstable版の1.30.6とmainline版の1.31.7で修正されました。告知に載っている修正済みの版は「1.30.6以降」と「1.31.7以降」だけで、1.28系などそれより前の系列向けの修正版はありません。

対象の版の範囲はCVEごとに違います。たとえばCVE-2026-93479は、nginx.orgの告知では1.30.0〜1.30.5と1.31.2〜1.31.6だけが対象です。一方、Ubuntuは22.04 LTSや24.04 LTSの版でもこの件を修正しています（UbuntuのCVEのページの注記は、Ubuntuが9月の更新（24.04 LTSでは 1.24.0-2ubuntu7.18）で取り込んだCVE-2026-42533の修正に合わせた調整に触れています）。Ubuntuのパッケージを使っている場合は、本家の版番号ではなく、USNの修正版で判断してください。

編集部の検証環境（Ubuntu 24.04.5 LTSのコンテナ）で、2026年10月27日に apt-get install nginx を実行したところ、1.24.0-2ubuntu7.19 が入りました。ここで注意したいのは、nginx -v の表示です。

$ nginx -v
nginx version: nginx/1.24.0 (Ubuntu)
$ dpkg-query -W -f='${Package} ${Version}\n' nginx nginx-common
nginx 1.24.0-2ubuntu7.19
nginx-common 1.24.0-2ubuntu7.19

比較のため、24.04 LTSのリリース時の版（1.24.0-2ubuntu7）に戻して同じコマンドを実行しても、nginx -v の表示は「nginx/1.24.0 (Ubuntu)」で変わりませんでした。nginx -v が表示するのは本家の版番号だけで、Ubuntuのパッケージの版の末尾は出ません。修正済みかどうかは、パッケージの版（末尾の ubuntu7.19 まで）で確かめます。

パッケージの変更履歴（/usr/share/doc/nginx/changelog.Debian.gz）にも、7.19 で4件のCVEを修正したことが記録されていました。

nginx (1.24.0-2ubuntu7.19) noble-security; urgency=medium
  * SECURITY UPDATE: heap overflow in certain configurations
    - CVE-2026-15176
  * SECURITY UPDATE: heap overflow in certain configurations
    - CVE-2026-93479
  * SECURITY UPDATE: UaF when asynchronous file I/O is enabled
    - CVE-2026-97205
  * SECURITY UPDATE: client SSL session forgery
    - CVE-2026-97629

（抜粋。24.04 LTSが対象外のCVE-2026-95101は含まれていません）

自社の設定に条件があるか洗い出す

更新はすべてのサーバーで行うとして、並行して「条件に当たる設定があるか」を見ておくと、優先順位や、更新までの間に取る対策を決めやすくなります。編集部では、nginx -T（読み込まれる設定をすべて表示する）の出力から、5件に関係するディレクティブを拾うスクリプトを作りました。

#!/bin/sh
# nginx -T の出力から、USN-8955-1 の5件のCVEの条件に関係するディレクティブを拾う
# 拾えたら即「脆弱」ではなく、該当の設定を人が読むための目印
conf=$(mktemp)
nginx -T 2>/dev/null > "$conf" || { echo "nginx -T に失敗（root権限が必要な場合あり）"; exit 1; }
hit() { printf '\n[%s] %s\n' "$1" "$2"; grep -nE "$3" "$conf" | grep -vE '^[0-9]+:\s*#' | head -20; }
hit CVE-2026-15176 "alias と rewrite と \$request_filename の組み合わせ" '^\s*(alias|rewrite)\s|\$request_filename'
hit CVE-2026-93479 "正規表現の map と、root・log_format でのキャプチャ変数" '^\s*map\s|^\s*~|^\s*(root|log_format)\s.*\$([0-9]|[a-z_]+)'
hit CVE-2026-95101 "HTTP/3 と proxy_request_buffering" '\bquic\b|http3|proxy_request_buffering'
hit CVE-2026-97205 "aio と SSI" '^\s*(aio|ssi)\s'
hit CVE-2026-97629 "共有セッションキャッシュとチケットキー、クライアント証明書" '^\s*ssl_(session_cache\s+shared|session_ticket_key|session_tickets|verify_client)\b'
rm -f "$conf"

検証環境では、条件に当たる書き方を含む設定ファイルを1つ用意し、nginx -t で文法が正しいことを確かめてから実行しました。出力は次のとおりです（行番号は nginx -T の出力の中の位置）。

[CVE-2026-15176] alias と rewrite と $request_filename の組み合わせ
205:        alias /srv/files/;
206:        rewrite ^/files/old/(.*)$ /files/$1 break;
207:        set $target $request_filename;

[CVE-2026-93479] 正規表現の map と、root・log_format でのキャプチャ変数
190:map $uri $legacy_dir {
191:    ~^/old/(?<section>[a-z]+)/  /srv/legacy/$section;
194:log_format withsec '$remote_addr $section $legacy_dir';

[CVE-2026-95101] HTTP/3 と proxy_request_buffering

[CVE-2026-97205] aio と SSI
210:        ssi on;
211:        aio threads;

[CVE-2026-97629] 共有セッションキャッシュとチケットキー、クライアント証明書
200:    ssl_session_cache   shared:SSL:10m;
201:    ssl_verify_client   optional;

その設定を外し、Ubuntuの初期設定だけで実行したときは、5件とも何も拾いませんでした。

このスクリプトは、条件に関係する行を見つけるための目印です。拾った行があっても脆弱とは限らず、拾わなかったからといって安全とも言い切れません。たとえばCVE-2026-93479の説明には「キャッシュされない変数を文字列の式で使う」という別の条件も書かれていますが、これは文字列の検索では判定できません。拾った箇所は、上の表の条件と突き合わせて人が読み、最終的にはパッケージの更新で対処します。

更新までの進め方（編集部の提案）

ここからは、編集部の整理です。

1. 管理しているサーバーと、Ubuntuのリリース・nginxのパッケージの版を一覧にする（dpkg-query の結果を集める）
2. 上のスクリプトで、条件に当たる設定のあるサーバーを先に把握する
3. 修正版に更新し、nginx -t で設定を確かめてから、nginxが新しいバイナリで動いていることを確認する
4. CVE-2026-97629 の条件（共有のセッションキャッシュとクライアント証明書の検証）に当たるサーバーでは、更新までの間、チケットキーを明示するか、セッションチケットを止める設定も検討する

4の設定変更は、Ubuntuの通知やCVEのページが緩和策として示しているものではなく、条件の説明から編集部が考えた選択肢です。変更する場合は、検証環境で動作を確かめてから適用してください。また、20.04 LTS以前は、5件のうち3件が「Needs evaluation（評価中）」となっています。古いリリースのサーバーが残っている場合は、OSの更新も含めて計画する必要があります。

古いサーバーの放置が問題になる構図は、React2Shellから半年たっても放置サイトで残る脆弱性でも取り上げました。nginxの保守体制そのものの考え方は、nginxの重大脆弱性と構成監査も参考になります。

確認した範囲

2026年10月27日に、Ubuntuのセキュリティ通知 USN-8955-1 と、5件のCVEのページを確認しました（資料調査）。あわせて、編集部の検証環境（Ubuntu 24.04.5 LTSのコンテナ）に nginx 1.24.0-2ubuntu7.19 を入れ、版の表示（リリース時の 1.24.0-2ubuntu7 との比較を含む）、パッケージの変更履歴、上のスクリプトの出力を確かめました（実機検証）。脆弱性の再現、サービスとしての起動・再起動の確認は行っていません。あわせて、開発元のnginx.orgのセキュリティ告知と変更履歴（CHANGES）で、本家の修正版と対象の版の範囲を確かめました。

自社のWebサーバーやシステムの更新・保守の進め方は、開発・AI・自動化のご相談からお問い合わせください。

参考資料

• USN-8955-1: nginx vulnerabilities（Ubuntu、2026-10-26）
• nginx security advisories（nginx.org）
• Changes with nginx 1.30.6（nginx.org、2026-10-14）
• CVE-2026-15176（Ubuntu）
• CVE-2026-93479（Ubuntu）
• CVE-2026-95101（Ubuntu）
• CVE-2026-97205（Ubuntu）
• CVE-2026-97629（Ubuntu）