NGINX Rift（CVE-2026-42945）が緊急とされる理由と発見の経緯

NGINX Rift（CVE-2026-42945）が緊急とされる理由と発見の経緯

CVE-2026-42945、通称「NGINX Rift」は、世界で最も広く使われるWebサーバーの一つであるnginxに見つかった深刻な脆弱性です。2008年から18年もの間ソースコードに潜み続けていた点と、条件次第でリモートコード実行（RCE）につながる点が大きな話題となりました。ここではまず、いつ・誰が・どのように公表したのか、そしてなぜ「緊急」と評価されるのかという全体像を整理し、後続の対応判断の土台を作っていきます。

2026年5月13日にF5とDepthFirstが協調開示した事実関係

CVE-2026-42945は、米国時間の2026年5月13日に、nginxの開発元であるF5とセキュリティ研究企業DepthFirstによって協調開示された脆弱性です。協調開示とは、問題を発見した研究者が一般公開の前にベンダーへ報告し、修正版の準備が整った段階で情報を同時に公表する進め方を指します。今回もDepthFirstがGitHubのセキュリティアドバイザリ経由で問題を報告し、F5が修正版の開発とアドバイザリ整備を進めたうえで両者が公表へ踏み切りました。攻撃者に悪用される前に利用者が更新へ動けるよう配慮された流れだと言えるでしょう。

公表と同時に、影響を受けるバージョンや修正版、技術的な解説が公開されています。日本国内でも複数のセキュリティ専門メディアが同日以降に報じており、利用者の裾野が広いソフトウェアであることから注目を集めました。まず押さえておきたいのは、これが特定ベンダー独自の製品ではなく、オープンソース版のnginxを含む広い対象を持つという事実です。自社には無関係だと早合点せず、開示された一次情報を起点に状況を確認していく姿勢が欠かせません。

2008年の0.6.27から18年間潜伏した経緯と見逃しの背景

この脆弱性で特に注目されたのは、その潜伏期間の長さです。発見元の解析によれば、原因となるコードは2008年にリリースされたバージョン0.6.27の時点ですでに混入しており、最新に近い1.30.0まで影響が及ぶとされています。実に18年近くにわたり、世界中の多くのサーバーが気づかぬまま該当コードを動かし続けていた計算になります。広く使われ、長く監査されてきたはずのソフトウェアでも、こうした見逃しが起こりうるという点が大きな教訓になりました。

なぜこれほど長く見つからなかったのかという背景には、発動条件の特殊さがあります。後述するように、この問題は単にnginxを動かしているだけで顕在化するものではなく、特定のディレクティブの組み合わせが設定されている場合にのみ表面化するものです。そのため通常の動作確認やコードレビューでは異常として現れにくく、長期間にわたり潜伏し続けたと考えられます。日常的に問題なく稼働しているという事実が、安全性の証明にはならないことを示す事例だと整理できます。

DepthFirstの自動解析システムが脆弱性を発見した手法

今回の発見は、人手による地道なコード監査ではなく、DepthFirstが開発した自律的な解析システムによってもたらされました。同社の説明によると、nginxのリポジトリを取り込んで解析を起動するだけで作業が始まり、約6時間のスキャンを経て複数のセキュリティ上の問題が検出されたとされています。そのなかには、rewriteディレクティブの処理に関わる深刻度の高いヒープオーバーフローも含まれていました。低レベルなソフトウェアの解析に特化した仕組みが、長年見逃されてきた問題を浮かび上がらせた形です。

検出された候補のうち、最終的にnginx側で正式に確認されたのは4件でした。各指摘に対しては、脆弱性の説明だけでなく根本原因の分析や、システムが自動生成した実証コードが添えられたと公表されています。注目すべきは、ソフトウェア解析の自動化が現実の重大な発見につながった点です。攻撃者側も同種の手法を使える可能性があるため、防御側にとっては「未知の潜在的な欠陥が突然表面化しうる」という前提で備える必要性が高まっていると言えます。

rewrite処理で起きるヒープバッファオーバーフローの仕組み

CVE-2026-42945の本質は、URLの書き換え処理を担うngx_http_rewrite_moduleにおけるヒープバッファオーバーフローです。nginxはrewriteやsetといったディレクティブを高速に処理するため、内部のスクリプトエンジンが二段階の処理を行います。一段階目で出力に必要なメモリ長を計算して領域を確保し、二段階目で実際のデータを書き込む仕組みです。この設計は効率的ですが、二段階の間でエンジンの内部状態が変化すると、確保した領域と書き込む量がずれてしまう危険をはらんでいます。

具体的には、rewriteの置換文字列に疑問符が含まれるとis_argsという内部フラグが立ち、それが後続の処理にまたがって残り続けます。長さ計算の段階では初期化された別エンジンが使われるためエスケープ分の長さが見積もられず、実際の書き込み段階で攻撃者が制御可能なエスケープ済みデータが想定より大きく書き込まれます。結果として確保済み領域の境界を越える上書きが発生し、メモリ破壊に至るという流れです。難解に見えますが、要は「計算した量より多く書いてしまう」古典的な不整合が原因だと捉えると理解しやすくなります。

通称NGINX RiftとCVE-2026-42945が指す対象の対応関係

報道や解説では「NGINX Rift」という通称が頻繁に使われますが、これは発見元が付けた呼び名であり、正式な識別子はCVE-2026-42945です。一般にCVE番号は脆弱性ごとに一意に割り当てられる管理番号で、ベンダーやデータベースをまたいで同じ問題を指し示すために用いられます。情報を収集する際は、キャッチーな通称ではなくCVE番号を軸に追うほうが、対象を取り違える失敗を避けられます。

注意したいのは、「NGINX Rift」という言葉が、文脈によって今回確認された4件全体を漠然と指す場合と、最も深刻なCVE-2026-42945の一件だけを指す場合があるという点です。狭義にはRift＝CVE-2026-42945ですが、まとめ記事では複数件を含めて語られることもあります。自社の対応範囲を検討するときは、どのCVEについて述べているのかを必ず確認し、番号単位で影響と修正状況を突き合わせることが、抜け漏れのない対応につながります。

4件のメモリ破壊脆弱性の内訳とCritical評価をめぐる解釈の違い

今回nginx側で確認された脆弱性は4件あり、いずれもメモリ破壊に分類される問題です。ただし深刻度には差があり、RCEに至りうるCVE-2026-42945が突出して重い一方、残りは主にサービス停止や情報の読み取りに関わるものです。さらにCVE-2026-42945は、CVSSスコア上はCriticalと評価されながら、悪用に特定の条件を要するため実際の危険度をめぐる解釈が分かれました。この章では4件の全体像と、評価が分かれる背景を整理します。

DepthFirstの解析でNGINX側に確認された4件の脆弱性の内訳

確認された4件は、影響するモジュールも症状も異なります。最も重いのがrewrite処理のヒープバッファオーバーフローであるCVE-2026-42945で、これだけがRCEに直結しうる位置づけです。残る3件は、過大なメモリ割り当てによるワーカープロセスのクラッシュ、TLS関連処理での解放後使用、文字コード変換処理での領域外読み取りであり、深刻度は中〜高にとどまります。まず全体像を一覧で把握しておきましょう。

この一覧からわかるとおり、4件は「同じくらい危険」なわけではありません。対応の優先順位を決める際は、まずCVE-2026-42945への該当可否を確認し、続いて自社が使うモジュール構成に照らして残り3件の影響を見ていくと整理しやすくなります。なお深刻度の数値は発見元およびデータベースの評価であり、ベンダー公式の評価とは異なる場合がある点には留意してください。

CVE-2026-42945以外の3件の脆弱性と影響度の違いの比較

CVE-2026-42945以外の3件は、いずれもRCEには直結しにくく、影響の性質が異なります。CVE-2026-42946はSCGI／uWSGI連携処理で、上流からの応答読み取りに不整合が生じるとおよそ1テラバイトという非現実的なサイズの確保を試み、ワーカープロセスがクラッシュするものです。これはサービス停止（DoS）型のリスクであり、リバースプロキシとして特定の構成を組んでいる場合に影響します。深刻度はHighと比較的高めに評価されています。

残るCVE-2026-40701とCVE-2026-42934はいずれもMediumです。前者はTLS関連処理で、OCSPのDNS解決が完了する前に接続が閉じられると解放済みのメモリを参照してしまう解放後使用の問題とされています。後者は文字コード変換処理での領域外読み取りで、不完全なUTF-8シーケンスの扱いに起因し、確保領域の手前を数バイト読み取る挙動が報告されました。いずれも特定の機能を有効にしている環境で問題になりうるもので、自社がどのモジュールを使っているかによって影響の有無が変わってきます。

CVSSスコアはCriticalながら実際の危険度が割れる理由

利用者を困惑させたのが、CVSSスコアの高さと、専門家の慎重な反応との間にあるギャップです。F5の公式アドバイザリおよびNVDは、この脆弱性をCVSS 4.0で9.2（Critical）、CVSS 3.1で8.1（High）と評価しており、スコア上は最高水準に近い深刻度に位置づけられています。発見元のDepthFirstもCriticalと表現し、メディアの見出しの多くも「緊急」という評価を採用しました。一方で、悪用には特定のrewrite設定が必要で、コード実行にはASLR無効化という追加条件も要することから、過度な警戒を戒める声も出ています。

この受け止めの差は、評価がどの前提に立つかによって生じます。CVSSスコアは、RCEという到達点の深刻さと潜在的な影響範囲の広さを重視した値です。これに対し警戒を緩める立場は、すべてのnginxが直ちに危険なわけではなく、特定の設定と環境条件が揃って初めてリスクが現実化する点を強調します。どちらかが誤りというより、見ている観点が違うと理解するのが妥当です。実務では、スコアの高さに過度に振り回されるのでもなく、安心しきるのでもなく、自社の条件に当てはめて判断する必要があります。

CVSS v4で9.2・v3.1で8.1となるスコア算出の根拠

付与されたスコアを見ると、評価指標のバージョンによっても数値が異なります。F5およびNVDの情報では、CVSS 4.0の基本値が9.2で深刻度はCritical、より古いCVSS 3.1の基本値が8.1で深刻度はHighとされています。同じ脆弱性でも、新旧どちらの指標で測るかによってCriticalにもHighにも見えるわけです。引用元によって「9.2」「8.1」と数字が違って見えるのは、このバージョン差が背景にあると考えると整理できます。

CVSS 4.0は3.1に比べ、悪用の難易度や攻撃成立に必要な前提条件、影響の波及範囲をより細かく反映する設計になっています。今回のように、特定設定とASLR無効という条件下でRCEに至る種類の脆弱性では、条件の重みづけの違いがそのまま最終スコアの差となって表れやすくなります。重要なのは、どの数字が「正しい」かを競うことではなく、いずれの指標でもHigh以上の深刻度に位置づけられているという事実を押さえることです。少なくとも軽視してよい問題ではないと判断できます。

CVSS上の深刻度と実際の悪用条件を踏まえた実務での深刻度の判断基準

評価をめぐる受け止めが分かれる状況で実務担当者が取るべき姿勢は、「条件が限定的だから大丈夫」と安心するのではなく、自社環境に即して保守的に判断することです。深刻度のスコアはあくまで一般化された目安であり、同じ脆弱性でも、攻撃者から到達可能な位置にサーバーが置かれているかどうかで実際のリスクは大きく変わります。自社のnginxがインターネットに直接公開され、かつ該当設定を持つなら、現実のリスクはCritical相当として扱うのが安全です。

判断の手がかりとして、次の三点を順に確認すると整理しやすくなります。第一に、稼働中のバージョンが影響範囲に含まれるか。第二に、悪用の前提となる設定が存在するか。第三に、当該サーバーが外部から到達可能かどうかです。これらがすべて当てはまる場合は、表記上の深刻度に関わらず優先度を引き上げるべきです。逆にいずれかが外れていればリスクは下がりますが、その判断根拠を記録し、構成変更時に再評価できるようにしておくことが望まれます。

影響を受けるNGINXバージョン範囲と自社環境の該当判定基準

対応の出発点は、自社が動かしているnginxが影響範囲に含まれるかどうかの確認です。今回の脆弱性はオープンソース版とNGINX Plusに加え、同じコードを取り込んだNGINX Ingress ControllerやApp Protectなど複数のF5・NGINX製品にも影響しますが、対象となるバージョンの範囲は明確に示されています。一方で、同じF5の名を冠していても影響を受けない製品もあるため、製品名だけで判断すると取り違えが起きかねません。ここではバージョン範囲と、確実に切り分けるための確認手順を順に押さえていきます。

NGINX Open Source 0.6.27〜1.30.0が対象となる範囲

オープンソース版のnginxについては、CVE-2026-42945の影響範囲は2008年リリースのバージョン0.6.27から1.30.0までとされています。つまり、長年運用してきた古い環境はもちろん、比較的最近のバージョンであっても1.30.0以前であれば対象に含まれます。「新しいから大丈夫」という思い込みは禁物で、具体的な番号と突き合わせて判断することが重要です。逆に言えば、後述する修正版へ更新済みであれば、この脆弱性に関しては対象外となります。

注意したいのは、影響範囲に含まれること自体が、即座に攻撃可能であることを意味しない点です。CVE-2026-42945は特定のrewrite設定がある場合にのみ発動するため、対象バージョンであっても該当設定がなければこの脆弱性は成立しません。ただし、設定はいつでも変更されうるものですし、4件のうち他の脆弱性は別の条件で影響する可能性もあります。まずは「対象バージョンか否か」を機械的に確認し、そのうえで設定面の精査へ進むという二段構えで臨むのが堅実です。

NGINX Plus R32〜R36が影響を受けるバージョン条件

商用版のNGINX Plusについては、公開された情報によると、R32からR36までのリリースが影響を受けるとされています。NGINX PlusはオープンソースのnginxをベースにF5が提供する製品で、サポートや追加機能が付属する点が特徴です。バージョン体系がオープンソース版とは異なり「R＋数字」という形式で表されるため、自社が利用しているのがどちらの系統かをまず明確にする必要があります。両者を混同すると、確認すべき番号を取り違えてしまいます。

NGINX Plusを利用している場合は、契約しているサポート経由で最新のアドバイザリ情報を入手できることが多く、対象バージョンや推奨される更新先を公式の窓口から確認できます。商用版は本番環境の中核に据えられているケースが多いため、影響範囲に含まれると判明した場合の優先度は相応に高くなります。なお、利用中のリリースがR32より前、あるいは修正が取り込まれた後続リリースであれば、この脆弱性については対象外と整理できますが、必ず正式な情報で裏取りをしてください。

nginx -Vで稼働バージョンとビルド構成を確認する実務手順

自社のnginxがどのバージョンかは、サーバー上でコマンドを実行すれば確認できます。バージョン番号だけを知りたい場合は小文字のnginx -vを、ビルド時のオプションや組み込まれたモジュールまで把握したい場合は大文字のnginx -Vを使います。今回の脆弱性は特定モジュールに関わるため、どのモジュールが組み込まれているかまで見える後者の確認が有効です。出力には、バージョンに続いてコンパイル時の構成情報が表示されます。

確認の際は、複数のnginxが混在していないかにも注意が必要です。OSのパッケージで入れたものと、手元でビルドしたものが両方存在し、起動しているのは別物だったという取り違えは珍しくありません。実際に稼働中のプロセスが参照している実行ファイルを特定したうえで、そのファイルに対してnginx -Vを実行することが肝心です。コンテナで運用している場合は、ホスト側ではなくコンテナ内部のバージョンを確認しないと、実体とずれた結論を出してしまう点にも気をつけてください。

影響を受けないF5製品とNGINX One Consoleの切り分け

F5は数多くの製品を提供しており、その中には今回の脆弱性の影響を受けないものもあります。製品名にNGINXやF5が含まれているというだけで「危ない」と判断すると、不要な対応に追われたり、逆に本当に対象の製品を見落としたりする原因になります。公開情報で影響を受けないとされている主な製品は次のとおりで、これらについては今回の脆弱性を理由とした緊急の更新は基本的に不要です。

• F5 Distributed Cloud Services
• F5 Silverline
• NGINX One Console
• BIG-IP
• BIG-IQ
• F5OS
• Traffix SDC
• F5 AI Gateway

逆に、明確に対象となるのはオープンソース版のnginxとR32〜R36のNGINX Plusで、加えてNGINX Instance Manager、F5 WAF for NGINX、NGINX App Protect、NGINX Gateway Fabric、NGINX Ingress Controllerなど同一コードを組み込んだ製品も影響を受けます。重要なのは、自社で動いている実体がどの製品・どのバージョンなのかを一つずつ突き合わせることです。クラウドのマネージドサービスやアプライアンス製品として提供されている場合は提供元の案内に従えばよく、自前でnginxを構築・運用している環境ほど自力での確認と更新が求められると整理しておくと判断がぶれません。

パッケージ版とディストリビューション同梱版での確認方法の違い

同じnginxでも、入手経路によってバージョンの確認方法や更新の段取りが変わります。nginx公式のリポジトリから導入した場合は、比較的素直に公式の最新バージョンへ追従できるのが利点です。一方、OSのディストリビューションが提供するパッケージを使っている場合は、ディストリビューション側が独自にセキュリティ修正だけをバックポートしていることがあり、表示されるバージョン番号が公式の番号と一致しないことがあります。番号だけで判断すると、修正済みなのに未対応と誤認する事態が起こりえます。

このため、ディストリビューション同梱版を使っている環境では、表面的なバージョン番号に加えて、配布元のセキュリティ情報で当該CVEが修正済みとされているかを確認するのが確実です。具体的には、利用中のディストリビューションのセキュリティ勧告でCVE-2026-42945が対応済みと案内されているか、パッケージの更新履歴に該当修正が含まれているかを見ます。公式リポジトリ版とディストリビューション版で確認の着眼点が違うことを理解しておくと、判定の精度が上がります。

攻撃が成立するrewrite設定パターンと安全な環境の切り分け

CVE-2026-42945は、対象バージョンであれば常に危険というわけではなく、特定のrewrite設定が存在する場合にのみ発動します。逆に言えば、設定面を正しく確認できれば、自社が本当にリスクを抱えているのかを切り分けられるのです。ここでは、攻撃が成立する設定パターンの特徴と、安全側に判断してよい条件、そして誤認しやすい落とし穴を整理していきます。設定の読み解きが、過不足のない対応の鍵になります。

攻撃の前提となる無名PCREキャプチャを含むrewrite設定

この脆弱性の発動には、正規表現を使ったrewriteと、その結果を参照する後続ディレクティブの組み合わせが関わります。発見元の解説では、無名キャプチャ（$1、$2など）を用い、置換文字列に疑問符を含むrewriteの後に、後続のrewrite・if・setのいずれかが続くと、内部状態の不整合が顕在化すると報告されました。たとえば、次のような形でキャプチャグループを使い、置換結果に疑問符を含めるような設定が典型例として挙げられます。

具体的には、rewrite ^/api/(.*)$ /v2/api/$1?; の直後に set $original_path $1; が続くような記述が該当します。

上記はあくまで条件を説明するための概念的な例であり、これそのものが直ちに攻撃コードになるわけではありません。ポイントは、正規表現のキャプチャ、疑問符を含む置換、そしてキャプチャを参照する後続処理という要素が一つの流れの中で揃うことです。API gatewayのように、リクエストパスを書き換えつつ元のパスを変数へ退避するような構成では、こうした組み合わせが自然に登場しやすいため、該当しないかを丁寧に点検する価値があります。

?を含むreplacementと後続ディレクティブが揃う3条件

攻撃成立の前提を、もう少し噛み砕いて条件として整理すると理解しやすくなります。第一の条件は、rewriteの置換文字列に疑問符が含まれていることです。これにより内部のフラグが立ち、その状態が後続処理へ持ち越されます。第二の条件は、直前の正規表現でキャプチャ（丸括弧で囲んだ部分）が使われていることです。第三の条件は、そのキャプチャを参照する後続のrewrite・if・setのいずれかが続くことです。

これら三つが一連の処理の中で同時に成立したときに、長さ計算と書き込みの不整合が引き起こされます。裏を返せば、いずれか一つでも欠けていれば、この特定の経路では問題は発動しません。たとえば、rewriteは使っているが置換に疑問符を含めていない、あるいはキャプチャを後続で参照していないといったケースでは、少なくともCVE-2026-42945の発動条件は満たしません。自社設定を点検する際は、この三条件を一つの組として見ていくと、該当・非該当の判断がぶれにくくなります。

rewriteを使っていない環境が直ちに危険ではない判断基準

重要な前提として、CVE-2026-42945はrewriteとsetの特定の組み合わせがなければ発動しません。したがって、rewriteディレクティブをまったく使っていない、あるいは静的ファイルの配信やシンプルなプロキシ用途にとどまる構成であれば、この脆弱性に関して直ちに危険とは言えません。対象バージョンであっても、発動条件を満たさない限りこの経路での攻撃は成立しないため、過度に慌てる必要はないと判断できます。

ただし、これは「更新しなくてよい」という意味ではない点に注意してください。設定は運用の都合でいつでも追加・変更されますし、今回確認された4件のうち他の脆弱性は別の条件で影響する可能性があります。当面の緊急度は下げられても、恒久的な安全のためには修正版への更新が結論になります。実務的には、「現時点では発動条件を満たさないため緊急度は中程度」と評価しつつ、計画的な更新を予定に組み込む、という整理が現実的です。

自社のnginx.confでrewrite設定を確認する実務手順

該当設定の有無は、設定ファイルを横断的に検索することで把握できます。nginxの設定はnginx.conf本体だけでなく、includeで読み込まれる複数のファイルに分散していることが多いため、設定ディレクトリ全体を対象に調べるのが確実です。たとえば設定ディレクトリ配下を再帰的に検索し、rewriteとsetの記述箇所を洗い出してから、置換文字列に疑問符が含まれていないか、キャプチャを参照していないかを目視で確認します。

grep -rEn "rewrite|set " /etc/nginx/

このコマンドは設定ディレクトリ以下からrewriteとsetを含む行を行番号付きで抽出する例です。抽出結果をもとに、前述の三条件が一連で成立している箇所がないかを点検します。include構成が複雑な場合は、nginx -Tで実際に読み込まれる設定全体を展開して確認すると、見落としを防げます。検索で何も出てこなければCVE-2026-42945の該当可能性は低いと判断できますが、最終的な安全は更新によって担保するのが基本方針です。

該当設定があると誤認しやすいrewrite設定パターンの失敗例

設定の点検では、本来は安全なのに危険と誤認したり、逆に危険なのに見落としたりする失敗が起こりがちです。よくある誤認の一つは、rewriteという単語が含まれているだけで一律に「該当」と判断してしまうケースです。前述のとおり発動には三条件の同時成立が必要であり、単純なリダイレクト用のrewriteや、疑問符・キャプチャ参照を伴わない記述は、この脆弱性の経路には当たりません。過剰反応は不要な作業を生みます。

逆に見落としやすいのは、設定が複数ファイルやincludeに分散していて、rewriteとsetが離れた場所に書かれている場合です。一つのファイルだけを見て安全と即断すると、別ファイルの後続処理で条件が揃っている状況を取りこぼします。マップ変数やテンプレートで設定を生成している環境では、展開後の最終形を確認しないと実態がつかめないこともあります。検索と展開を併用し、ファイル単位ではなく「実際に読み込まれる設定全体」を一つのまとまりとして見ることが、誤認を避ける近道です。

RCEとDoSの分岐点となるASLR設定とリスク度合いの評価

CVE-2026-42945は、発動条件を満たした場合でも、その結末は環境によって変わります。多くの環境ではワーカープロセスのクラッシュ、すなわちサービス停止にとどまりますが、特定の条件下ではリモートコード実行に至る可能性が指摘されています。その分岐を左右する代表的な要素がASLRという防御機構です。ここでは、何が結果を分けるのか、そして自社のリスクをどう見積もるべきかを整理します。

ASLRが有効でDoS・無効でRCEに至る攻撃結果の分岐条件

発見元の検証によると、この脆弱性を悪用された場合、ASLR（アドレス空間配置のランダム化）が有効な環境では主にワーカープロセスのクラッシュ、つまりサービス停止につながります。一方、ASLRが無効化されている環境では、攻撃者が任意のコードを実行できる、いわゆるRCEが成立しうるとされています。同じ脆弱性でも、防御機構の状態によって「止まるだけ」か「乗っ取られる」かという、影響の重さがまったく異なってくるわけです。

ASLRは、プログラムが使うメモリ上の配置を起動のたびにランダム化することで、攻撃者が狙った場所を正確に言い当てにくくする仕組みです。現在の主要なLinuxディストリビューションでは標準で有効になっているため、多くの本番環境ではいきなりRCEに直結するわけではありません。ただし、これはあくまで「成立しにくい」のであって「絶対に成立しない」ではない点に注意が必要です。クラッシュによるサービス停止自体も十分な実害であり、ASLRが有効だからと安心しきるのは禁物だと言えます。

ワーカープロセスのクラッシュと自動再起動が及ぼすサービス実害

RCEに至らない場合でも、ワーカープロセスのクラッシュは無視できない影響を及ぼします。nginxは複数のワーカープロセスでリクエストを処理する構成が一般的で、攻撃によってワーカーが落ちると、そのプロセスが処理していた接続は中断されてしまうのです。マスタープロセスが落ちたワーカーを再起動する仕組みはありますが、攻撃が繰り返されれば、その都度クラッシュと再起動が起き、サービスの応答が不安定になります。

特に、認証を必要とせず外部からのリクエスト一つで発動しうる性質を踏まえると、攻撃者が継続的にリクエストを送り続けるだけで、実質的なサービス妨害（DoS）が成立してしまいます。可用性が事業に直結するサービスでは、コード実行に至らないとしても、この停止リスクだけで対応を急ぐ十分な理由になります。「RCEでなければ軽微」という発想ではなく、サービスが止まること自体の業務影響を基準に優先度を考えることが大切です。繰り返し攻撃を受ければ、監視やアラートへの対応にも人手が割かれ、運用負荷の面でも見過ごせない負担が生じます。

Linux環境でASLRが有効か無効かを確認する具体的な実務手順

自社サーバーのASLRが有効かどうかは、Linux環境であればカーネルの設定値を読むことで確認できます。具体的には、設定値を保持するファイルを直接参照する方法が一般的です。値が0であればASLRは無効、1または2であれば有効を意味し、多くのディストリビューションでは標準で2が設定されています。確認には次のいずれかのコマンドが使えます。

具体的には、cat /proc/sys/kernel/randomize_va_space を実行するか、sysctl kernel.randomize_va_space で値を確認します。

もし値が0になっていた場合は、過去のチューニングやアプリケーションの都合でASLRを意図的に無効化している可能性があります。その状態は今回の脆弱性に関してはRCEのリスクを高める要因となるため、無効化の必要性を改めて見直す価値があります。なお、ASLRはあくまで悪用を困難にする緩和策の一つであり、有効であっても脆弱性そのものが消えるわけではありません。確認結果はリスク評価の材料として扱い、最終的な解消は修正版への更新で行うのが筋です。

認証が不要なまま外部から攻撃が成立する点が高めるリスクの度合い

この脆弱性のリスクを押し上げている要因の一つが、悪用に認証を必要としない点です。発見元の説明によれば、攻撃者は細工したHTTPリクエストを送るだけで、事前のログインや権限取得なしに問題を発動させられるとされています。インターネットに公開されたWebサーバーは、不特定多数からのリクエストを受け付ける前提で動いているため、認証不要という条件は攻撃の敷居を大きく下げることになります。

加えて、nginxはWebサービスやAPIの最前段、リバースプロキシ、クラウドやコンテナ基盤の入り口など、外部と接する位置に置かれることが多いソフトウェアです。攻撃者から見れば到達しやすく、かつ重要な位置にあるため、悪用に成功した際の波及は背後のシステムにまで及びかねません。認証不要・外部到達可能・該当設定ありという条件が重なる環境ほどリスクは高いと評価し、対応の優先順位を引き上げる判断が妥当です。とりわけ外部公開かつ該当設定ありの環境では、攻撃の試行コストが低いことを前提に、早期対応を既定の方針とするのが安全だと言えます。

自社環境をRCE・DoS・影響なしで切り分けるリスク判断基準

ここまでの要素を踏まえると、自社環境のリスクは大きく三段階で切り分けられます。最も重いのは、対象バージョンであり、発動条件となるrewrite設定を持ち、さらにASLRが無効で、かつ外部から到達可能なケースです。この場合はRCEまで視野に入る最優先の対応対象となります。次に重いのは、対象バージョンかつ該当設定はあるが、ASLRが有効でインターネットへの露出が限定的なケースで、主にサービス停止リスクとして扱います。

そして、対象バージョンであっても該当設定がない、あるいはそもそも外部から到達できない内部限定の環境であれば、当面の緊急度は相対的に低いと判断できます。ただし、いずれの段階であっても恒久的な解決は修正版への更新です。判断基準を整理しておくことで、限られた人員と時間をどこから投入すべきかが見えやすくなります。なお、この切り分けの根拠は文書として残し、構成変更や設定追加のたびに再評価できるようにしておくことをおすすめします。

NGINX修正済みバージョン一覧とアップデート実施時の注意点

恒久的な対策は、修正が取り込まれたバージョンへ更新することです。F5は今回の脆弱性に対応した修正版を公開しており、オープンソース版・商用版それぞれに更新先が用意されています。ここでは、どのバージョンへ上げればよいのか、自社の系統に応じた選び方、そして更新作業でつまずきやすい点を整理します。なお具体的なバージョン番号は、必ず公式アドバイザリで最新の表記を確認してください。

NGINX Open Source 1.30.1・1.31.0で修正された内容

オープンソース版については、公開された情報によると、安定版系統の1.30.1と、新しい系統の1.31.0で今回の脆弱性が修正されたとされています。基本的な考え方として、現在1.30系を使っているのであれば1.30.1へ、より新しい機能系統を追っているのであれば1.31.0へ更新する、という対応になります。いずれにせよ、影響範囲の上限である1.30.0以前から、修正が取り込まれたバージョンへ移行することが解決の条件です。

更新にあたっては、単にバージョンを上げるだけでなく、自社で利用している設定やモジュールが新バージョンでも問題なく動くかを事前に確認することが欠かせません。マイナーな更新であっても、まれに挙動の差異が生じることがあります。可能であれば検証環境で先に動作を確かめ、設定の互換性や起動の可否をチェックしてから本番に適用すると安全です。修正版の正確な番号と適用対象は、適用直前に改めて公式情報で裏取りすることをおすすめします。

NGINX Plus R36 P4・R32 P6・R37.0.0の修正対応状況

商用版のNGINX Plusについては、公開された情報によると、影響を受ける各リリース系統に対して修正を含むバージョンが提供されています。利用中のリリースに応じて、対応するパッチ適用版または後続リリースへ更新する形が基本です。系統ごとの修正適用先の対応関係を整理すると、次のようになります。

NGINX Plusは契約に基づくサポートが付くため、対象判定や更新先の確認をサポート窓口経由で行えるのが利点です。表で挙げたR36・R32以外でも、影響範囲に含まれるリリース（例：R35）には対応するパッチが用意されているため、利用中のリリースに合う修正版を選びます。本番の中核として運用しているケースが多いことから、影響対象と判明した場合は計画的かつ迅速な適用が求められます。バージョン表記は公開情報に基づく整理であり、適用前には必ずF5公式アドバイザリ（K000161019）で対象と更新先を確認してください。

稼働中のバージョン系統に応じた適切な修正版の選び方の判断基準

修正版の選択で迷いやすいのが、安定性を優先するか、新機能を取り込むかという観点です。判断の基準はシンプルで、原則として「いま使っている系統の中で、修正が取り込まれた最も近いバージョン」へ上げるのが安全です。大きく系統をまたぐアップグレードは、機能や設定の互換性に関わる検証コストが増えるため、緊急のセキュリティ対応としては避けたほうが無難な場合が多いと言えます。

たとえばオープンソース版で1.30系を運用しているなら、まずは1.30.1への更新を第一候補とし、別系統への移行は別途計画として切り出すのが現実的です。商用版であれば、利用中のリリースに対応するパッチ適用版を選ぶのが基本線になります。重要なのは、セキュリティ修正の適用と、機能アップグレードを混同しないことです。両者を一度にまとめて行うと、不具合が出たときにどちらが原因かの切り分けが難しくなり、復旧が遅れる失敗につながります。セキュリティ対応はまず脆弱性を確実に消すことを最優先とし、機能の更新は落ち着いてから別途進めるという切り分けで臨むのが堅実です。

アップデートの前に設定ファイルとモジュール構成を確認する手順

更新作業を安全に進めるには、事前準備が結果を大きく左右します。まず、現在の設定ファイル一式と、組み込まれているモジュールの構成を控えておくことが出発点です。前述のnginx -Vでビルド構成を記録し、設定ディレクトリ全体のバックアップを取得しておくと、万一のロールバック時に役立ちます。次に、新しいバージョンで設定の文法に問題がないかを確かめる準備を整えます。

具体的には、更新後に設定の検証を行ってから反映する流れが基本です。設定の妥当性チェックにはnginx -tが使え、これで構文エラーや読み込み不能なファイルがないかを事前に把握できます。サードパーティ製モジュールを利用している場合は、新バージョンとの互換性が保たれているかも確認が必要です。検証環境がある場合はそこで一連の流れを通しで試し、本番では同じ手順をなぞるだけにしておくと、想定外の停止を避けやすくなります。あわせて、更新後に問題が起きた場合の切り戻し手順と判断の基準もあらかじめ決めておくと、復旧の局面で迷わずに動けます。

再起動を伴うアップデート適用作業で起こりがちな失敗のパターン

更新の最終段階では、新しいバイナリを反映させるための再起動やリロードが必要になります。ここで起こりがちな失敗の一つが、設定の検証を省いたまま再起動し、構文エラーでサービスが起動しなくなるケースです。事前にnginx -tで確認していれば防げる事故であり、検証を飛ばさないことが何より大切だと言えます。もう一つは、リロードと再起動を取り違え、古いプロセスが残ったまま新旧が混在してしまうパターンです。

また、パッケージの更新自体は完了していても、稼働中のプロセスが古いバイナリをメモリに保持し続け、実際には修正が反映されていないという見落としも頻発します。更新後は、稼働プロセスが新しいバージョンで動いているかを必ず確認してください。さらに、複数台構成やロードバランサ配下では、一台ずつ順に更新して可用性を保つ段取りが求められます。慌てて全台同時に作業すると、想定外の停止時に逃げ場がなくなる点にも注意が必要です。

アップデートを即時適用できない環境向けの暫定緩和策と回避手順

修正版への更新が最善である一方、検証や調整の都合で即座に適用できない環境も現実には存在します。そうした場合に、リスクを一時的に下げるための暫定的な手当てがいくつか挙げられるのです。ただし暫定策はあくまでつなぎであり、副作用や限界も伴います。ここでは、設定面とネットワーク面の緩和策、そのトレードオフ、そして緩和策が恒久対応の代替にならない理由を整理します。

該当するrewrite設定を一時的に見直して回避する暫定緩和策

CVE-2026-42945は三つの条件が揃ったときにのみ発動するため、そのうちの一つを崩すことで発動を回避できます。F5が公式に推奨する緩和策は、脆弱性の前提となる無名キャプチャ（$1、$2）を、名前付きキャプチャ（(?<name>...)）へ書き換える方法です。名前付きキャプチャは脆弱なエスケープ処理の経路を通らないため、設定の意図を保ったまま発動条件を解消できる点が利点です。

名前付きキャプチャへの書き換えはアプリケーションの挙動を変えにくい緩和策ですが、設定を変更する以上は影響がないことの確認が欠かせません。リクエストパスの書き換えや元パスの保存は背後のアプリケーションが前提としている挙動であることが多く、書き換えを誤ると機能不全を招きかねません。緩和策を適用する場合は、変更前の設定を必ず保全し、検証環境で影響を確かめたうえで、範囲を限定して反映するのが鉄則です。緩和の効果と業務影響を見極め、慎重に判断してください。

WAFや前段プロキシで不正なリクエストを遮断する暫定的な方法

nginx本体に手を入れにくい場合は、その手前に位置する防御層で攻撃リクエストを遮断するアプローチもあります。WAF（Web Application Firewall）や前段のリバースプロキシ、CDNのルールを使い、悪用に用いられる特徴的なリクエストパターンをブロックする考え方です。前段で止められれば、脆弱なnginxに到達する前にリクエストを弾けるため、攻撃の成立を妨げる効果が期待できます。

もっとも、この手法は万能ではありません。攻撃パターンを過不足なく定義するのは難しく、ルールが緩ければすり抜けを許し、厳しすぎれば正規のリクエストまで巻き込んで誤遮断を起こします。脆弱性の性質上、何をもって不正と判定するかの線引きも単純ではありません。前段防御はあくまで時間を稼ぐための緩和であり、根本解決ではないと割り切ることが大切です。導入する場合は誤検知の監視をセットにし、正常な通信を妨げていないかを継続的に確認してください。

暫定対応で生じる機能制限とサービスへの影響のトレードオフの比較

暫定緩和策には、それぞれ異なる副作用が伴うものです。設定変更による回避は、発動条件を確実に崩せる反面、アプリケーションの挙動を変えてしまい、想定していたパス書き換えや変数の受け渡しが機能しなくなるおそれがあります。一方、前段でのリクエスト遮断は、nginxの設定や挙動に手を加えずに済む反面、ルールの精度に依存し、すり抜けや誤遮断という別のリスクを抱え込みます。どちらを採るにせよ、得るものと失うものを天秤にかける視点が欠かせません。

判断にあたっては、対象サービスの性質を軸に考えると整理しやすくなります。可用性が最優先で、わずかな機能制限なら許容できるサービスでは設定変更が現実的なこともありますし、設定に触れたくない本番では前段遮断のほうが扱いやすいでしょう。いずれの暫定策も、適用後に意図しない影響が出ていないかを観察する運用とセットにして初めて意味を持ちます。緩和策の選択は、効果の大きさだけでなく、自社が許容できる副作用の種類から逆算するのが賢明です。

暫定的な緩和策の適用後も恒久対応としての更新が必要となる理由

暫定緩和策を講じても、脆弱なコードそのものはサーバー上に残り続けます。設定変更による回避は運用の都合でいつでも元に戻されうるものですし、前段の遮断ルールも、攻撃手法の変化や設定の見直しによって有効性が損なわれかねません。つまり緩和策は、リスクを一時的に下げているにすぎず、根本原因を取り除いてはいないという点を正しく認識しておく必要があります。

さらに、今回確認された脆弱性は4件あり、暫定的に一つの発動経路を塞いだとしても、他の問題への耐性が得られるわけではありません。恒久的な解決はあくまで修正版への更新であり、暫定策はその更新を安全に行うまでの時間を稼ぐ手段だと位置づけるのが適切です。緩和策を入れたことで対応が完了したと誤認し、更新計画を棚上げしてしまうのが最も危うい失敗です。暫定策の導入と同時に、いつ恒久対応を行うかの期限を必ず決めておきましょう。緩和策の有効期限をあらかじめ明示し、その期日までに更新を完了させる前提で計画を組むことが、対応の形骸化を防ぐうえで有効です。

暫定的な緩和策を実施する際の具体的な作業手順と確認項目の整理

暫定緩和策を実施する際は、行き当たりばったりではなく、手順と確認項目を明確にしてから着手することが事故を防ぎます。まず、変更前の状態を完全に保全し、いつでも元に戻せる状態にしておくことが前提です。次に、検証環境で緩和策を適用し、攻撃経路が塞がれること、そして正規の機能が損なわれないことの両方を確認します。問題がなければ、影響範囲を限定したうえで本番へ反映するという流れです。

反映後の確認項目としては、対象サービスが正常に応答しているか、誤遮断や機能不全が発生していないか、ログに想定外のエラーが出ていないかが挙げられます。あわせて、緩和策を入れた事実と内容、適用日時、担当者を記録に残しておくと、後の恒久対応や監査の際に役立つはずです。暫定策はあくまで一時的な措置である以上、解除のタイミングや恒久対応の期限まで含めて文書化しておくことが、対応の抜け漏れを防ぐ要になります。誰が見ても現在の状態と次に取るべき行動がわかる形で記録を残しておけば、担当者の交代や引き継ぎがあっても対応を途切れさせずに済みます。

公開後の悪用状況とPoC流通を踏まえた対応の優先度と判断基準

最後に、公開後の状況を踏まえて、自社がどの程度急いで動くべきかを判断する視点を整理します。実環境での悪用が観測されているか、攻撃の手がかりとなる情報がどこまで出回っているかは、優先度を決めるうえで重要な材料です。あわせて、18年潜伏という今回の事例から、個別対応にとどまらない再発防止の教訓も引き出せます。情報の鮮度に注意しつつ、現実的な行動へ落とし込みましょう。

公開3日後の5月16日から悪用の試みが観測され始めた最新状況

悪用の状況は短期間で大きく動きました。F5や発見元は、開示時点（2026年5月13日）では実環境での悪用を把握していないとしていました。しかし脆弱性研究企業VulnCheckによれば、同社の観測システムは公開からわずか3日後の5月16日に悪用の試みを検知し始めたと報告しています。これは技術詳細とPoCが公開された直後のタイミングであり、開示から数日のうちに攻撃側が動き出したことを示しています。

観測された悪用の試みがどこまで成功するかは、標的の環境に左右されます。既定構成のnginxではサービス停止が成立しうる一方、コード実行は前述のとおりASLRが無効な環境などに限られると指摘されています。とはいえ、すでに攻撃の試行が始まっている以上、「まだ被害が出ていない」ことを先送りの理由にはできません。広く使われるソフトウェアは攻撃者にとって魅力的な標的であり、対応の遅れがそのまま被害につながりかねない局面に入ったと捉えるべきです。最新の動向は継続して確認してください。

GitHubで公開されたPoCコードがもたらす悪用リスクの高まり

今回のケースで特に警戒すべきなのは、概念実証コード、いわゆるPoCが公開されている点です。発見元はGitHub上で実証コードを公開しており、これにより脆弱性を再現するためのハードルは大きく下がっています。PoCは本来、利用者が自環境の影響を確認したり、修正の効果を検証したりするための正当な目的で公開されるものですが、同時に攻撃者にとっても悪用の足がかりになりうるという二面性があります。

PoCが出回っている状況では、高度な技術を持たない攻撃者でも既存のコードを流用して攻撃を試みやすくなり、悪用の裾野が広がります。実際に、PoC公開の直後から悪用の試みが観測され始めたことは、この危険性が現実のものであることを裏づけています。したがって、PoC公開済みという事実は、対応の優先度を一段引き上げる判断材料として受け止めるべきです。とりわけ外部公開サーバーで該当条件を満たす環境は、可能な限り早期の更新を強くおすすめします。

インターネットへの公開状況に応じた自社の対応優先度の判断基準

対応の優先度を決める最大の分かれ目は、対象のnginxが外部から到達可能かどうかです。インターネットに直接公開され、不特定多数からのリクエストを受け付けるサーバーは、攻撃者の射程に入っているため、最優先で対応すべき対象になります。逆に、外部から直接アクセスできない内部ネットワーク限定のサーバーであれば、即時の危険度は相対的に下がり、計画的な更新で対応できる場合が多くなります。

判断の際は、ロードバランサやCDN、ファイアウォールといった前段の構成も含めて、実際にどこまで外部から届くのかを正確に把握することが重要です。「内部向けのつもりだったが、実は特定のポートが公開されていた」といった想定外の露出は珍しくありません。公開状況、該当バージョンか否か、発動条件となる設定の有無、ASLRの状態という複数の軸を組み合わせ、最も条件が重なるサーバーから順に手をつけるのが、限られたリソースを有効に使う現実的な進め方です。

18年間潜伏した脆弱性が示す依存ソフトウェア管理の教訓と対策

今回の事例は、個別の脆弱性対応を超えて、依存するソフトウェアをどう管理するかという普遍的な課題を突きつけています。18年もの間、広く使われ続けたソフトウェアに重大な欠陥が潜んでいたという事実は、「枯れているから安全」「広く使われているから検証済み」という思い込みが必ずしも正しくないことを示しています。長期間問題なく動いてきたという実績は、未知の脆弱性が存在しないことの証明にはなりません。

実務的な対策としては、利用しているソフトウェアとそのバージョンを把握する仕組みを整え、セキュリティ情報を継続的に追える体制を持つことが基本になります。何をどのバージョンで使っているかが即座に分からなければ、脆弱性が公表されても自社が影響を受けるかを素早く判断できません。また、自動化されたコード解析の進展により、これまで見逃されてきた問題が今後も次々と表面化する可能性があります。発見が増える前提で、平時から更新しやすい運用を整えておくことが、結果的に有事の対応速度を左右します。

公開後に取るべき対応を時系列で整理した実務担当者向け行動指針

ここまでの内容を、実務担当者がそのまま着手できる時系列の行動として整理します。重要なのは、いきなり更新作業に飛びつくのではなく、影響範囲とリスクを確認してから、状況に応じた手段を選ぶという順序です。次の流れに沿って進めると、抜け漏れを抑えつつ効率的に対応できます。

1. 稼働中のnginxのバージョンと製品種別を特定し、影響範囲に含まれるかを確認する
2. 発動条件となるrewriteとsetの設定が存在しないか、設定全体を横断的に点検する
3. 外部からの到達性とASLRの状態を確認し、RCE・DoS・低リスクのいずれに該当するかを評価する
4. 修正版へ更新する。即時更新が難しい場合は暫定緩和策を適用し、恒久対応の期限を設定する
5. 更新・緩和の適用後に稼働バージョンと動作を検証し、対応内容を記録して継続的に監視する

この一連の流れを、最も外部に露出し条件の重なるサーバーから順に適用していくのが効果的です。あわせて、今回の対応で得た「自社が何をどのバージョンで使っているか」という情報は、次の脆弱性公表時にも必ず役立ちます。一度きりの対応で終わらせず、ソフトウェアの棚卸しとセキュリティ情報の追跡を平時の運用に組み込むことが、将来の同種事案への備えになります。