Webサーバー管理者向けNGINX Rift対応マニュアル｜影響判定・apt/dnfパッチ・WAF緩和を30分で

ＨＯＭＥ＞リナックスマスター.JP 公式ブログ＞ Linux情報・技術・セキュリティ＞ Webサーバー管理者向けNGINX Rift対応マニュアル｜影響判定・apt/dnfパッチ・WAF緩和を30分で

この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）

「うちのnginx、18年前のコードのまま動いてるかもしれない」

そう言われて素直に「いや、さすがに最新版だよ」と返せた人は、たぶんそんなにいないと思います。私自身、最初に CVE-2026-42945 の概要を見たとき、頭の中に浮かんだのは検証機のことではなく、何年も前にお客さんに納品して、その後リプレースされずに動き続けている本番のリバースプロキシのことでした。

2026年5月13日、F5 とセキュリティ研究者集団 depthfirst が、nginx の ngx_http_rewrite_module に18年潜伏していた重大なヒープバッファオーバーフロー脆弱性を公開しました。CVE 番号は CVE-2026-42945、通称は「NGINX Rift」。CVSS v4.0 は 9.2、CRITICAL です。影響範囲は 0.6.27 から 1.30.0 までと、現役で動いている nginx のほぼ全世代を巻き込みます。

本稿は「設計思想の話」ではなく、今日・明日のうちに本番機で何を打つかという実務オペ寄りに振った内容です。影響有無の判定、apt と dnf の両系統でのパッチ適用、それからすぐに再起動できない事情を抱えているサーバーのための一時的緩和まで、コマンド付きで整理します。手元に検証機を1台立ち上げて、上から順に試しながら読んでください。

「このままじゃマズい」と感じていませんか？

参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。

図解60P／登録10秒／解除も3秒／詳細はこちら

NGINX Rift（CVE-2026-42945）とは何か——3行とコマンド1発で押さえる

3行で押さえると、こうなります。

・nginx の rewrite モジュールに、unnamed PCRE capture（$1、$2 など）と「?」を含む置換文字列、その後に続く if/set/rewrite ディレクティブが揃ったときだけ発火するヒープバッファオーバーフロー
・未認証の攻撃者がHTTPリクエスト1発で worker プロセスをクラッシュさせられる。ASLR が無効な環境ではリモートコード実行に発展する
・影響は nginx 0.6.27 から 1.30.0 まで18年分。Open Source 1.30.1 / 1.31.0、NGINX Plus R32 P6 / R36 P4 / 37.0.0 で修正済み

公式情報を抜き出すと次のとおりです。

・CVE番号: CVE-2026-42945
・通称: NGINX Rift
・CWE: CWE-122（ヒープベース・バッファオーバーフロー）
・CVSS v4.0: 9.2 CRITICAL（CNA: F5 Networks）
・CVSS v3.1: 8.1 HIGH（同）
・発見・報告: depthfirst（責任ある開示 2026-04-21、公開 2026-05-13）
・F5 アドバイザリ: K000161019
・NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-42945

実際に動いている悪用についてですが、Phemex（仮想通貨系メディア）は「悪用報告あり、更新済みは30%未満」と伝えていますが、F5公式・The Hacker News・Qualys ThreatPROTECT・NSFOCUS の発表を読む限り、5月18日時点で in-the-wild の本格的な悪用キャンペーンは確認されていません。「悪用が確認された」と断言するのは時期尚早ですが、PoC が GitHub の DepthFirstDisclosures/Nginx-Rift で公開されているため、本気の攻撃者にとっては時間の問題と考えるのが妥当です。

自分の手元のサーバーが対象かどうかを30秒で確認するなら、まず次のコマンドです。

nginx -v

出力例として「nginx version: nginx/1.24.0 (Ubuntu)」のような行が返ってきます。表示されたバージョン番号が 1.30.0 以下なら、配布元のパッチ番号を確認するまで「影響あり」のラベルで扱ってください。0.x 系（0.6.27 ～ 0.9.7）は upstream として修正版が提供されないため、ディストリ側パッチが当たっているかが命綱になります。

あなたのサーバーは本当に対象か——影響判定の3点チェック

「nginx -v」のバージョンだけで判定を終わらせると痛い目を見ます。理由は2つあります。

1つ目は、Debian / Ubuntu / RHEL / AlmaLinux などのディストリビューションは、upstream のバージョン番号を上げずに、自前でパッチを当てた「修正版」をリリースする運用をしているからです。たとえば Ubuntu 24.04 LTS の nginx は「nginx/1.24.0」と名乗りますが、パッケージ実体としては「1.24.0-2ubuntu7.8」というバージョンになっていて、ここに CVE-2026-42945 修正が含まれます。「nginx -v だけ見て 1.24.0 だから影響あり」と判断すると、すでに直っているサーバーまで停止再起動を巻き込むことになります。

2つ目は、そもそも ngx_http_rewrite_module を使っていなければ実害の発火条件が成立しない、という点です。rewrite 文を一切書いていない静的配信専用のサーバーであれば、CVSS 9.2 とはいえ即座にRCEに走られるわけではありません（とはいえモジュールはバイナリに静的リンクされているのが普通なので、パッチは当てる前提で話を進めます）。

判定手順は次の3点です。検証機で実際に打ってみてください。

判定1: パッケージ実体のバージョンを確認する

Debian / Ubuntu 系:

dpkg -l nginx | grep ^ii
apt changelog nginx | head -30

dpkg -l の出力の3列目にあるのが実際のパッケージバージョンです。apt changelog の方は、ここ最近のセキュリティ修正の履歴が頭から並びます。「CVE-2026-42945」という文字列が含まれていれば、そのバージョンには修正が入っています。

RHEL / AlmaLinux / Rocky Linux 系:

rpm -q nginx
rpm -q --changelog nginx | head -50

rpm -q --changelog の出力に「CVE-2026-42945」または「nginx-rift」の文字列があれば、当たっています。AlmaLinux の場合は「1.20.1-24.el9_7.2.alma.2」「1.24.0-5.2.alma.1」「1.26.3-2.1.alma.1」「1.26.3-2.el10_1.1.alma.1」あたりが該当バージョンです。

判定2: rewrite ディレクティブの利用状況を確認する

nginx.conf 全体から rewrite を grep で抜きます。

sudo nginx -T 2>/dev/null | grep -nE 'rewrite|if \(|set \$' | head -40

nginx -T はインクルードされた設定ファイル全てを結合して標準出力に吐く便利オプションです。出力に「rewrite ... $1 ...」「rewrite ... $2 ...」のように unnamed capture を使っている行があり、置換文字列に「?」が含まれていて、その後の location ブロックに if や set が連なっている場合、最も発火しやすい構成です。WordPress や Movable Type のリライト周り、独自CMS の URL 正規化、HTTP → HTTPS の301リダイレクト処理あたりが該当しがちです。

判定3: ASLR の有効性を確認する

クラッシュ（DoS）止まりで済むか、RCEまで発展するかの分岐点が ASLR の有無です。

cat /proc/sys/kernel/randomize_va_space

返り値が「2」なら ASLR は有効です。「0」なら無効で、悪用条件が一気に揃います。意図的に 0 にしている運用は基本ありませんが、過去の組込み系や古いコンテナイメージで稀に見かけます。0 だった場合は、パッチ適用と並行して「echo 2 | sudo tee /proc/sys/kernel/randomize_va_space」と /etc/sysctl.conf への kernel.randomize_va_space = 2 追記を即実行してください。

判定1で「未パッチ」、判定2で「unnamed capture と ? を含む rewrite が存在」、判定3で「ASLR=2」だった場合、DoS リスクは高いがいきなりのRCEは届きにくい、というのが現時点の評価です。判定3が 0 だった場合は、最優先で 2 に戻す、を最初の一手にしてください。

PR / rewrite と nginx 設定を体系的に押さえたい方へ

nginx実践入門（WEB+DB PRESS plus） 久保達彦・道井俊介 / 技術評論社 / 2016年

基本設定・rewrite・リバースプロキシ・HTTPS まで、nginx の運用で踏みやすい所が一通り押さえられる定番書。今回の rewrite 周りの判定をやる前に手元に1冊置いておくと、自社の nginx.conf を読み解く速度が変わります。

apt 系（Ubuntu / Debian）でのパッチ適用手順

Ubuntu / Debian 側の修正状況を整理します。

Ubuntu（USN-8271-1、2026年5月14日リリース）:

・22.04 LTS（jammy）: nginx 1.18.0-6ubuntu14.11
・24.04 LTS（noble）: nginx 1.24.0-2ubuntu7.8
・25.10（oracular）: nginx 1.28.0-6ubuntu1.3
・26.04 LTS（plucky）: nginx 1.28.3-2ubuntu1.1

Debian（DSA-6278-1）:

・bookworm（12）: 1.22.1-9+deb12u7
・trixie（13）: 1.26.3-3+deb13u5

適用手順は基本に忠実で大丈夫です。

sudo apt update
sudo apt list --upgradable 2>/dev/null | grep nginx
sudo apt install --only-upgrade nginx nginx-common nginx-core
nginx -v
sudo nginx -t
sudo systemctl reload nginx

最後の reload で worker プロセスが新しいバイナリで再起動します。restart ではなく reload を選ぶことで、TCP接続を抱えている既存の worker は処理を完了してから死ぬので、ダウンタイムなしで切り替わります。ただし master プロセスは古いバイナリのまま動き続ける点に注意してください。本当の意味で全プロセスを新バイナリに揃えたい場合は、master プロセスに USR2 シグナルを送って新 master を起こし、その後 WINCH と QUIT を順番に送る「ホット・リロード」が必要です。ここは長くなるので別記事にします。

リバースプロキシで止められないサーバーは、systemctl reload nginx だけ走らせる、で運用上は十分です。

適用後の検証は次の3つを必ず行ってください。

nginx -v
dpkg -l nginx | grep ^ii
sudo journalctl -u nginx --since "10 min ago" | tail -20

journalctl 側に「reloading」「worker process N exited」「signal 1 (SIGHUP) received」あたりが見えていれば、worker は無事に新バイナリで起動しています。クライアントの 502 / 504 が一時的に出ていないかも、アクセスログで確認します。

dnf 系（RHEL / AlmaLinux / Rocky）でのパッチ適用手順

RHEL 系は module stream が絡むため、apt 系より少し手数が増えます。AlmaLinux 公式アドバイザリで公開されている対応バージョンが、現状もっとも参照しやすいので、それを軸に書きます。Rocky Linux や RHEL 本家でも、同じバージョン系列で同等のパッチが提供されているはずです（必ずディストリ公式のセキュリティアドバイザリで確認してください）。

AlmaLinux 8 系（module stream 利用）:

sudo dnf module list nginx
sudo dnf clean metadata
sudo dnf upgrade nginx
rpm -q nginx
sudo nginx -t
sudo systemctl reload nginx

stream 別の修正版バージョン:

・default（1.14）: nginx-1.14.1-9.el8.10.alma.1 以上
・nginx:1.16 stream: 1.16.1-2.1.el8.10.alma.1 以上
・nginx:1.18 stream: 1.18.0-3.1.el8.10.alma.1 以上
・nginx:1.20 stream: 1.20.1-1.1.el8.10.alma.2 以上
・nginx:1.22 stream: 1.22.1-1.1.el8.10.alma.2 以上
・nginx:1.24 stream: 1.24.0-3.el8.10.alma.2 以上

AlmaLinux 9 系:

・default: nginx-1.20.1-24.el9_7.2.alma.2 以上
・nginx:1.24 stream: 1.24.0-5.2.alma.1 以上
・nginx:1.26 stream: 1.26.3-2.1.alma.1 以上

AlmaLinux 10 / Kitten 10 系:

・nginx-1.26.3-2.el10_1.1.alma.1 以上

ミラーの同期周期は最大で3時間と AlmaLinux 公式が明記しています。dnf update を打って「No packages marked for update」と返ってきても、3時間後に再度試すと出てくるパターンが想定されるので、見つからないときは時間を置いてからもう一度回してください。

EPEL 経由で nginx を入れている古い RHEL7 / CentOS7 環境は、もうサポートが切れているはずなので、これを機にディストリごとリプレースする計画に動くタイミングだと思います。「動いているから触らない」を続けてきたサーバーが、今回のように1ファイルのHTTPリクエストで worker を落とせる時代になりつつあります。

すぐに再起動できないサーバーの一時的緩和——named captureとWAF

本番のWebサーバーやリバースプロキシで、業務時間中にパッチを当てて reload を打つのが現実的に難しい現場は多いと思います。深夜帯までもたせるための一時的緩和を2層で書いておきます。

緩和1: rewrite を named capture に書換える（F5 公式推奨）

F5 のアドバイザリと depthfirst が公式に推奨している方法です。発火条件のひとつ「unnamed capture（$1, $2）」を、名前付きキャプチャ「(?<name>...)」に書き換えるだけで、脆弱な内部処理パスを通らなくなります。

たとえば、よくある書き方:

rewrite ^/old/(.*)$ /new/$1?legacy=1 permanent;

これを named capture に書き換えます:

rewrite ^/old/(?<path>.*)$ /new/$path?legacy=1 permanent;

書き換えたら必ず構文チェックと挙動テストです。

sudo nginx -t
sudo systemctl reload nginx
curl -I https://example.com/old/sample.html

「301 Moved Permanently」が返り、Location ヘッダで「/new/sample.html?legacy=1」を指していれば挙動はそのままです。

注意点として、これは「攻撃の入口を狭める」ものであって、ヒープバッファオーバーフロー自体の修正ではありません。あくまでパッチ適用までのつなぎとして使い、深夜帯に必ず正規パッチに切り替えてください。あと、unnamed capture を使っている rewrite 行を全部洗い出してから書き換えてください。1行残しは1行分の穴になります。

sudo nginx -T 2>/dev/null | grep -nE 'rewrite.*\$[0-9]'

これで該当行が抜けます。

緩和2: 前段 WAF / リバースプロキシでの URI フィルタリング

nginx の前段に AWS WAF、Cloudflare、Imperva、OPNsense、もしくは別の nginx を置いている場合は、不審な URI パターンを前段で落とす運用も併用できます。攻撃側は「rewrite に引っかかる特殊なURI」を投げてくるので、URIの長さや特殊文字の組合せをカウントするルールを追加します。

一次情報側で「これだけブロックすれば確実」というシグネチャは公開されていませんが、考え方としては:

・URI の長さが極端に長いリクエスト（例: 2KB 超）
・URI 内に PCRE メタ文字相当（「?」「(」「)」「[」「]」）が異常密度で含まれるリクエスト

このあたりをカウンタールールでブロックします。誤検知が出やすいので、まずは「監視のみ」で1日回し、誤検知率を見てから enforce に切り替えるのが安全です。これも本来パッチ適用までのつなぎなので、長期運用する設定ではありません。

緊急時にどうしても rewrite を止めたい場合は、該当 location ブロックの rewrite 行を一時的にコメントアウトして、200 を直接返す簡易ハンドラに差し替える、という荒技もあります。SEOへの影響は出ますが、不正アクセスで worker が連続クラッシュするよりはマシです。深夜パッチまでの数時間限定で使ってください。

NGINX Plus と派生製品、それから「修正版がない古い nginx」の話

NGINX Plus を商用契約で使っている場合は、次のいずれかにアップグレードします。

・R32 P6
・R36 P4
・37.0.0

F5 のサポートポータルから入手できる、契約者向けの正規パッケージで上書きします。手順はディストリ非依存で、F5 アドバイザリ K000161019 の指示に従ってください。

派生製品（NGINX Instance Manager、NGINX App Protect WAF、NGINX Gateway Fabric、NGINX Ingress Controller など）も影響を受ける、と F5 自身が認めています。本体だけ直して派生側を放置すると、結局そこから穴になります。クラスタの中で nginx を名乗っているコンポーネントを一覧化して、全部チェックしてください。Kubernetes 上の Ingress Controller などは Pod イメージのタグでバージョンが固定されているはずなので、Helm chart や Deployment の値を確認します。

そして、最後にもうひとつ。NGINX Open Source の 0.6.27 から 0.9.7 系列には、修正版が提供されません。15年以上前のリリースなので当然と言えば当然ですが、現役で動いているサーバーは「絶対にないとは言い切れない」のが2026年の現実です。組織内のレガシーサーバー、ベンダーから引き継いだ顧客環境、開発者がローカルで立てて忘れ去られたVM、考え出すと寒気がしますが、心当たりがある人は今日中にバージョン棚卸しをすることを強く勧めます。私自身、今週は手元の検証用ホストを全部回しました。1.10.x のままだったコンテナが1個出てきて、頭を抱えました。

0.x 系で動いているサーバーが見つかった場合の選択肢は3つです。

・ディストリ標準のサポート対象バージョン（Ubuntu 22.04 なら 1.18.0、AlmaLinux 9 なら 1.20.1 など）にバージョンアップする
・上記が無理なら、別ホストに新規構築して切り替える
・最低でも前段に WAF を立てて、URI フィルタで時間を稼ぎながら撤去計画を立てる

「動いているから触らない」は、もう判断として通用しません。18年前のコードが2026年5月に9.2 CRITICAL になった、という事実をそのまま受け止めるしかないと思っています。

まとめ——CVE-2026-42945 対応の30分作業フロー

最後に、本記事の手順を30分で回すための作業フローに圧縮します。

・10分: nginx -v、dpkg -l / rpm -q、apt changelog / rpm --changelog で実体バージョン確認
・5分: nginx -T | grep rewrite で unnamed capture と「?」の出現箇所を抽出
・5分: /proc/sys/kernel/randomize_va_space が 2 であることを確認
・10分: sudo apt install --only-upgrade nginx … か sudo dnf upgrade nginx … でパッチ適用、reload 後 journalctl で worker 起動確認

業務時間内に reload まで打てない場合は、その場で named capture への書換えだけ済ませて、深夜帯にパッチ本体を当てる、の2段構えで動きます。手順の中で1番優先順位が高いのは、判定3（ASLR の有効化）です。ここが 0 のまま放置されているサーバーは、いまの状態で1発のHTTPリクエストでRCEに届く可能性があるので、まず /proc/sys/kernel/randomize_va_space を 2 に戻すところから始めてください。

NGINX Rift は、Apache mod_rewrite の世代から触ってきた人ほど「同じ感覚で書いた nginx.conf」が踏みやすい構造をしています。設計思想や歴史の話は別記事に書きましたが（記事末尾の参考リンクから辿れます）、本稿は「今日と明日のうちに本番機で何を打つか」に絞りました。検証機を1台用意して、上から順に手を動かしながら身につけてください。コマンド1発分の習熟が、来週・再来週に出てくる別の脆弱性対応の速度を決めます。

参考

・NVD CVE-2026-42945: https://nvd.nist.gov/vuln/detail/CVE-2026-42945
・F5 アドバイザリ K000161019: https://my.f5.com/manage/s/article/K000161019
・depthfirst（発見者）: https://depthfirst.com/nginx-rift
・AlmaLinux 公式アドバイザリ: https://almalinux.org/blog/2026-05-13-nginx-rift-cve-2026-42945/
・Ubuntu USN-8271-1: https://ubuntu.com/security/notices/USN-8271-1
・Debian Security Tracker: https://security-tracker.debian.org/tracker/CVE-2026-42945
・Qualys ThreatPROTECT: https://threatprotect.qualys.com/2026/05/14/f5-nginx-remote-code-execution-vulnerability-cve-2026-42945/

PR / あわせて読みたい本

nginx実践ガイド（impress top gear）渡辺高志 / インプレス / 2016年
はじめてのLinuxサーバー構築入門2025 日経Linux編 / 日経BP / 2024年

nginx の構築・運用に加えて、Webサーバーを支える Linux 側（systemd・journalctl・パッケージ更新）の作法をまとめて押さえたい方向け。脆弱性対応の30分作業フローを「自分の現場でも回せる」状態に持っていく補強として有効です。

「脆弱性が出るたびに走り回る運用」から卒業したい方へ

nginx -v、apt changelog、rpm --changelog、/proc/sys/kernel/randomize_va_space。記事を読むだけでなく、検証機で繰り返し手を動かすことで初めて身につきます。
ネットの切れ端の情報を集めるのではなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。

今すぐ無料でダウンロード（登録10秒）＞＞図解60P『Linux入門マニュアル』を受け取る

※ 「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

登録10秒／合わなければ解除3秒／詳細はこちら

Linux無料マニュアル（図解60P）名前とメールで30秒登録

この記事を書いた人

宮崎智広（みやざきともひろ）

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。

次のページへ：Fragnesia（CVE-2026-46300）をRHEL系で検知する｜auditd・Falco・eBPFで非特権ユーザーの怪しいXFRM呼び出しを掴む
前のページへ：rootは取られていない、しかしSSHホスト鍵と/etc/shadowは漏れた｜CVE-2026-46333（ssh-keysign-pwn）の正体と運用手順
この記事の属するカテゴリ：Linux情報・技術・セキュリティへ戻る