トップ/記事一覧/NGINX Rift CVE-2026-42945:影響範囲・確認手順・暫定回避策
nginx-rift-cve-2026-42945-cover-ja

NGINX Rift CVE-2026-42945:影響範囲・確認手順・暫定回避策

NGINXに18年潜んだ重大脆弱性CVE-2026-42945(NGINX Rift/CVSS 9.2)が公開され、すでに実際の攻撃も始まっています。認証不要でサーバを乗っ取られる恐れあり。Rocky Linux・RHEL系・Ubuntu・Debian・SUSEのパッチ状況、確認コマンド、暫定回避策をディストリ別早見表でまとめます。

ニュース2026年5月15日公開最終更新 2026年6月1日
目次
この記事のポイント

NGINXに18年潜んだ重大脆弱性CVE-2026-42945(NGINX Rift/CVSS 9.2)が公開され、すでに実際の攻撃も始まっています。認証不要でサーバを乗っ取られる恐れあり。Rocky Linux・RHEL系・Ubuntu・Debian・SUSEのパッチ状況、確認コマンド、暫定回避策をディストリ別早見表でまとめます。

2026年5月13日、Webサーバとして広く使われているNGINXに、深刻な脆弱性が公開されました。CVE番号は CVE-2026-42945、コードネームは NGINX Rift です。Rocky Linux・RHEL系・Ubuntu・Debian など主要なLinuxのパッチ状況と確認手順を、本記事のディストリ別早見表にまとめています

CVSS v4.0スコアは9.2(Critical)。oss-security メーリングリストでの開示と同時に、攻撃の実証コード(PoC)が 発見者であるdepthfirstの研究記事で公開されており、ログイン認証も既存のセッションも不要で、外部から遠隔操作できてしまうリモートコード実行(RCE)が成立する可能性が指摘されています。

そして公開からわずか3日後の5月16日、セキュリティ企業VulnCheckが、実際にこの脆弱性を狙う攻撃が始まっていることを観測したと報告しました(後述)。The Hacker Newsは世界で約570万台のNGINXがインターネットに露出していると伝えており、対応は待ったなしの状況です。

影響を受けるのはNGINXに同梱されている ngx_http_rewrite_module(URL書き換えを担当するモジュール)で、2008年にリリースされたバージョン0.6.27から1.30.0までが対象です。The Hacker Newsの初報は「18年間検出されなかった欠陥」として報じています。本記事では、影響範囲、ディストリ別のパッチ状況、確認手順、暫定回避策を整理します。

nginx を踏ませた相手が抜くもの、ECサイト全部

18年前から仕込まれた書き換えモジュールの穴を本気で欲しがるのは、HTTPSが復号される境界に居座って静かに金を引き出すタイプです。インターネットの入口に立つNGINXを狙うのは、ECサイトのカード入力欄からカード番号を抜くスキマー(Magecart系のグループ)、ログイン画面に細工して社員アカウントを横取りする産業スパイ、暗号資産取引所や銀行のセッションCookieを狙う金融系の窃盗団、競合の動向を探る商業諜報屋です。NGINXはアプリの「前」に立つリバースプロキシなので、ここを奪われれば全てのHTTPリクエストとレスポンスが平文で読め、好きに書き換えられます。本CVEを踏ませた瞬間、攻撃者は前段サーバそのものを乗っ取られてしまい、決済フォームの送信内容が1件ずつ外部C2サーバへ複製されていきます。

前段プロキシを握られた先に起きることは一本道です。通過した会員のメールアドレスとパスワード、決済時のカード番号、API認証トークンがそのまま抜かれ、ダークウェブで名簿として転売され、その名簿を使った偽決済画面のフィッシングや本人なりすましの不正ログインに回り、最終的に他社サービスの銀行口座・SNS乗っ取りへと連鎖していきます。レスポンスに任意のJavaScriptを差し込めるということは、サイトを訪れた全ユーザーのブラウザに侵入する権利を握ったのと同じで、改竄ページからのマルウェア配布にも転用されます。

そしてこの代償は、最後にサイトの運営企業へ返ってきます。前段プロキシを通った全顧客のカード番号が漏れれば、PCI DSS違反の通告とカードブランドからの賠償請求、個人情報保護委員会への報告義務、被害者への通知と補償が一斉に降りかかります。「あの店で買うとカードが盗まれる」という評判の失墜は、9.2という数字には載りません。原因が単一CVEのパッチ未適用と判明すればサイバー保険でカバーされる範囲も縮むため、いまパッチを当てられるかどうかが運営の明暗を分けます。

影響を受けるNGINXのバージョン

F5公式アドバイザリ K000161019NGINX Security Advisoriesによると、影響範囲は商用版を含むNGINXファミリー全体に及びます。

製品影響バージョン修正バージョン
NGINX Open Source0.6.27 〜 1.30.01.30.1(stable)
1.31.0(mainline)
NGINX PlusR32 〜 R36R36-1
(R37 P1も提供)
NGINX Instance Manager2.16.0 〜 2.21.1F5アドバイザリ参照
NGINX App Protect WAF同梱NGINXに依存F5アドバイザリ参照
NGINX Gateway Fabric同梱NGINXに依存F5アドバイザリ参照
Ingress-NGINX Controller同梱NGINXに依存プロジェクト側で更新

2008年7月リリースの0.6.27から該当するため、18年間にわたり配布されたほぼ全てのNGINX Open Sourceに脆弱性が含まれていたことになります。BleepingComputerの報道は、対象範囲が事実上「現役で稼働するすべてのNGINX」に及ぶと指摘しています。

ここで注意したいのは、Linuxディストリビューション(Ubuntu や Rocky Linux など、Linuxの配布形態のこと)が配るNGINXのバージョン番号は、上の表とは別物だという点です。各ディストリは古い版のパッケージに修正だけを移植する「バックポート」を行うため、nginx -v が古い番号を表示していても、ディストリ側で修正済みのことがあります。自分の環境がどうなっているかは、次のディストリ別早見表で確認してください。

ディストリ別のパッチ状況早見表(Rocky・RHEL・Ubuntu・Debian・SUSE・Alpine)

主要なLinuxディストリビューションごとに、影響の有無、修正パッケージのバージョン、確認コマンドをまとめます。バージョン番号は各ディストリのセキュリティトラッカー(脆弱性の対応状況を公開する公式サイト)の本記事執筆時点(2026年6月1日)の情報に準拠しています。最新の状況は必ずリンク先で確認してください。

ディストリ対応状況修正パッケージ版確認コマンド
RHEL 9修正済み
(5月18日)
RHSA-2026:18029
(9.6 EUSは17794)
rpm -q nginx
dnf update nginx
Rocky Linux 9遅れて反映
(要確認)
nginx-1.20.1-
28.el9_8.2 以降
rpm -q nginx
dnf check-update
AlmaLinux 9修正済み
(5月14日)
nginx-1.20.1-
24.el9_7.2.alma.2 以降
rpm -q nginx
dnf upgrade nginx
AlmaLinux 8修正済みnginx-1.14.1-
9.el8.10.alma.1 以降
rpm -q nginx
Ubuntu 24.04 LTS修正済み1.24.0-
2ubuntu7.8 以降
dpkg -l nginx
apt update
Ubuntu 22.04 LTS修正済み1.18.0-
6ubuntu14.11 以降
dpkg -l nginx
Ubuntu 20.04 LTS評価中
(要追跡)
未提供
(暫定回避策で対応)
Ubuntu Security
参照
Debian 12 (bookworm)修正済み1.22.1-
9+deb12u7 以降
dpkg -l nginx
Debian 11 (bullseye)修正済み1.18.0-
6.1+deb11u6 以降
dpkg -l nginx
SUSE/openSUSE修正済み
(5月25日)
SLES15 SP6: 1.21.5-
150600.10.18.1 以降
rpm -q nginx
zypper patch
Alpine Linux修正済み1.30.1-r0 / edgeは
1.30.2-r1 以降
apk version nginx
apk upgrade nginx

表のとおり、修正の早さはディストリによってはっきり差が出ました。一次情報は Ubuntu SecurityDebian security trackerRed Hat CVESUSE CVEAlmaLinux公式ブログで随時更新されています。Ubuntu 20.04やそれ以前の長期サポート版は「評価中(needs evaluation)」のまま修正版が出ていないため、後述の暫定回避策で先に塞いでおくのが安全です。

Rocky Linux・RHEL系での影響と対処

RHEL系(RHEL本体・Rocky Linux・AlmaLinuxなど、Red Hat互換のディストリ)を使っている方が最も気にしているのは「自分のサーバはもう直っているのか」という点だと思います。ここはディストリごとに事情が分かれています。

RHEL本体は早く、5月15日にRHEL 9.6 EUS向けの RHSA-2026:17794、5月18日にRHEL 9向けの RHSA-2026:18029 をいずれもCritical扱いで公開しました。dnf update nginx で取得できます。

AlmaLinuxも速く、5月14日に全サポート版の本番リポジトリへ配布済みです。sudo dnf clean metadata && sudo dnf upgrade nginx のあと sudo systemctl restart nginx で適用できます。

問題は Rocky Linux です。Rocky Linux公式フォーラムのスレッドでは、AlmaLinuxが当てた後もRocky Linux 9.7のnginx 1.26が未修正のままという指摘がありました。Rockyは独自バックポートをせずRHELと1対1の互換を目指す方針のため、修正は nginx-1.20.1-28.el9_8.2 として9.8マイナーリリースに同梱される形になります。Critical脆弱性は security リポジトリへ先行投入されることもあるため、dnf check-update nginx で更新の有無をこまめに確認してください。リリースを待てない場合は、次の暫定回避策で設定側を先に塞ぐか、NGINX公式リポジトリから1.30.1以降を導入する選択肢もあります。

脆弱性の仕組み(rewriteモジュールのバグ)

NGINXの ngx_http_rewrite_module は、URLを別のURLに書き換えるための機能です。たとえば /old/foo へのアクセスを /new/foo に転送するような設定で使われます。

depthfirstの解析記事によれば、3つの条件が揃った設定で、ヒープバッファオーバーフロー(確保したメモリ領域より大きいデータを書き込んでしまうバグ)が発生します。

  1. rewrite ディレクティブの後ろに rewrite / if / set のいずれかが続く
  2. 名前なしの正規表現キャプチャ($1, $2 など)を使用している
  3. 置換文字列(rewriteの第二引数)に疑問符 ? が含まれる

該当する設定の例は以下のようなものです。

location /api/ {
    rewrite ^/api/(.*)$ /internal?migrated=true&path=$1 last;
    set $endpoint $1;
}

バグの本質は、書き込み先バッファの「サイズ計算」と「実際の書き込み」で異なるエスケープ前提が使われている点にあります。サイズ計算時はエスケープ処理をしない生バイト長で算出され、書き込み時には ngx_escape_uri() によって特定の文字が最大3バイトに展開されます。確保したバッファより大きいデータが書き込まれ、ヒープ領域が破壊されます。

depthfirstの自動解析システムは、NGINXのソースコードのスキャン開始から約6時間でこの脆弱性を含む5件のセキュリティ問題を検出したと報告しています。発見が人手の監査ではなくAIによる自動解析だった点も、今回の事案の特徴です。

侵害された場合の影響範囲と、すでに始まっている攻撃

F5公式アドバイザリは、攻撃成立時に発生する事象として、NGINXワーカープロセスの再起動(サービス停止)と、条件によってはリモートコード実行(RCE)を挙げています。F5公式の文面では「heap buffer overflow in the NGINX worker process, leading to a restart. Additionally, for systems with ASLR disabled, code execution is possible(NGINXワーカープロセスでヒープバッファオーバーフローが発生し再起動を引き起こす。さらに、ASLR が無効化されたシステムではコード実行が可能である)」とされています。

ASLR(Address Space Layout Randomization、メモリ配置をランダム化してこの種の攻撃を成立しにくくする防御機構)は、RHEL・Rocky・Ubuntu・Debianなど主要なLinuxの標準カーネルで有効化されており、その環境ではコード実行の成立条件は限定的です。一方、古い組み込み機器や、軽量化目的でASLRを無効化したコンテナ・カーネルパラメータを手動変更した環境では条件が成立し得ます。ただしdepthfirstのPoCには、別の脆弱性(同一ホスト上のファイル読み取りの穴)と組み合わせてASLRを回避するチェーンも含まれており、ASLR有効でも安心はできません。

そして重要なのは、これがもう机上の話ではないという点です。セキュリティ企業VulnCheckのPatrick Garrity氏は、同社のおとりサーバ(canary)がPoC公開からわずか3日後の5月16日に、この脆弱性を狙う攻撃の試行を検知し始めたと報告しました。Security Affairsもこれを「実環境での悪用が始まった」と伝えています。一方でセキュリティ研究者のKevin Beaumont氏は、悪用には特定のrewrite設定が前提となるため、攻撃者がその設定を知るか見つける必要があると指摘しており、全NGINXが即座に乗っ取られるわけではない、と冷静な見方も示しています。

該当条件想定される被害対応の目安
公開Webサーバとして
1.30.0以下のNGINX運用
かつ該当rewrite設定あり
外部からの単発リクエストで
ワーカープロセス再起動
(サービス断続)
最優先パッチ適用
暫定回避策の同時実施
上記条件+
ASLR無効環境
(古い組込・一部コンテナ)
認証不要のRCEが成立し得る
サーバ乗っ取りリスク
即時パッチ/
該当サーバ停止検討
Ingress-NGINX Controllerを
Kubernetesで運用
クラスタ前段でDoS/
ワーカー再起動
プロジェクトの
更新版へ移行
NGINX Plus R32-R36を
商用サポート契約下で運用
同上+契約条件下の対応R36-1へ更新
F5サポート経由
NGINXを内包する
サードパーティ製品の利用
製品側パッチ未提供の間
同じリスクを継承
ベンダーへ問い合わせ/
暫定回避策の適用

該当rewrite設定の有無は次節の確認コマンドで判定できます。攻撃がすでに始まっている以上、設定に心当たりがある環境は今日中に手を打つのが安全です。

NGINXのバージョン確認とパッチ適用手順

まず動作中のNGINXのバージョンを確認します。バージョン番号を見るコマンドには -v(小文字)と -V(大文字)の2種類があります。

コマンド出力内容
nginx -vバージョン番号のみ
nginx -Vバージョン番号+コンパイル時のオプション+OpenSSL/PCREのバージョン

ただし前述のとおり、UbuntuやRocky Linuxなどディストリのパッケージは古い版に修正を移植しているため、nginx -v の表示番号だけでは判定できません。ディストリ版を使っている場合は、上のディストリ別早見表のパッケージ版と、rpm -q nginx / dpkg -l nginx の出力を突き合わせて判断してください。NGINX公式リポジトリやソースビルドで入れた場合のみ、上流バージョンが1.30.1 / 1.31.0以降かどうかで判定します。

# 上流バージョン確認(公式リポジトリ/ソースビルド向け)
$ nginx -v
nginx version: nginx/1.28.0   # 1.30.0以下なら上流は影響対象

# ディストリ版のパッケージ番号確認
$ rpm -q nginx        # RHEL / Rocky / AlmaLinux / SUSE
$ dpkg -l nginx       # Ubuntu / Debian
$ apk version nginx   # Alpine

バージョンが影響対象だった場合、続いて該当する設定パターンが存在するかを確認します。Walbrixの解説記事でも紹介されている方法です。

# 全設定をダンプして rewrite を含む行を確認
$ nginx -T | grep -E 'rewrite|^\s*(if|set)\s'

# /etc/nginx 配下の設定ファイルから探す方法
$ grep -rni 'rewrite' /etc/nginx/

該当する rewrite 行に $1$2 といった名前なしキャプチャと、? を含む置換文字列が同時に存在し、かつその後ろに rewrite / if / set ディレクティブが続いていれば、攻撃成立条件を満たします。

パッチ適用はディストリごとに次の手順です。

# Debian / Ubuntu
$ sudo apt update
$ sudo apt install --only-upgrade nginx

# RHEL / Rocky / AlmaLinux
$ sudo dnf clean metadata
$ sudo dnf upgrade nginx
$ sudo systemctl restart nginx

# SUSE / openSUSE
$ sudo zypper refresh
$ sudo zypper patch

# Alpine
$ apk update && apk upgrade nginx

# Docker(公式イメージ)
$ docker pull nginx:1.30.1   # または nginx:1.31.0

# Kubernetes Ingress-NGINX(Helm)
$ helm repo update
$ helm upgrade ingress-nginx ingress-nginx/ingress-nginx

暫定回避策として、すぐにアップデートできない環境(Rocky Linuxの更新待ちやUbuntu 20.04など)では、該当 rewrite 設定の名前なしキャプチャを名前付きキャプチャに書き換えることで、攻撃条件から外せます。設定変更後は nginx -t で構文確認のうえ nginx -s reload を実行します(再起動不要)。

# 修正前(脆弱)
rewrite ^/api/(.*)$ /internal?migrated=true&path=$1 last;
set $endpoint $1;

# 修正後(名前付きキャプチャ)
rewrite ^/api/(?<path>.*)$ /internal?migrated=true&path=$path last;
set $endpoint $path;

CISA・F5・各機関の対応状況とKEV該否

本記事執筆時点(2026年6月1日)での各機関・各製品の対応状況を整理します。

F5(NGINX開発元): 2026年5月13日にアドバイザリK000161019を公開し、同日にNGINX Open Source 1.30.1(stable)と1.31.0(mainline)、NGINX Plus R36-1のパッチを提供しました。報告自体は4月21日に行われ、5月13日に公表されたという調整プロセスを経ています。

CISA(米サイバーセキュリティ・インフラセキュリティ庁)のKEV該否: 本記事執筆時点で、CISAが公開する「実際に攻撃されている脆弱性リスト(Known Exploited Vulnerabilities Catalog、KEV)」に本CVEは未登録です。VulnCheckが実際の攻撃試行を観測している一方で、CISAの公式カタログにはまだ載っていない状態です。PoCの公開・悪用の観測・影響範囲を踏まえれば、近い将来に追加される可能性は十分にあります。米政府機関と取引のある組織は、KEV登録時に厳しい修正期限が課される点も念頭に置いてください。

各Linuxディストリビューション: 前述のディストリ別早見表のとおり、AlmaLinux(5月14日)、RHEL(5月15〜18日)、Debian、Ubuntu主要版、SUSE(5月25日)が修正版を提供済みです。Rocky LinuxはRHELとの1対1互換方針のため、9.8マイナーリリースへの同梱という形でやや遅れて反映されます。AlmaLinuxのように個別ブログで状況を明示しているディストリもあるので、運用中のディストリの一次情報を確認してください。

日本国内の報道: @ITWalbrixなどが詳細な解説記事を公開しています。

関連記事として、同じ時期にLinuxカーネル側で報告された Linuxカーネルの脆弱性 Fragnesia(CVE-2026-46300)、その前段の Copy Fail(CVE-2026-31431)も、サーバ全体の足元を見直す観点で参考になります。

参照元

avatar-m-1

堀川 慎

Backend Engineer / AWS / Django / Go