【2026年7月版】nginxバージョンとOSによるバックポートについて

皆さんこんにちは。
taneCREATIVEの「ちほうタイガー」です。

本記事は、nginxのバージョンと、各種OSによるバックポート対応についてまとめたもので、2026年7月23日に改訂しています。

nginx（エンジンエックス）は、F5, Inc.が開発やサポートを継続しているオープンソースのWebサーバーソフトウェアの一つであり、W3Techsによれば、現時点で世界ナンバー1のシェアを有しています。

nginxの公式サポートは、アクティブサポートおよびセキュリティサポートの期間を厳密には区別しておらず、基本的にはリリース日から1年間で次の安定版がリリースされ、当該バージョンのサポートは終了します。
2026年7月23日現在、nginx安定版の最新バージョンは1.30系統であり、公式がセキュリティサポートをしている安定版バージョンも1.30系統のみです。
※nginxのバージョン情報とサポート期限についてはこちらをご覧ください。

もっとも、最新ではないnginxのバージョンを使用していても、直ちに危険な状態になるとは限りません。OSによっては、古くなったnginxのバージョンに対しても、緊急、重大な脆弱性に対してバックポートと呼ばれる方式で修正を適用するケースがあるためです。

そこで、この記事では、企業のWeb担当者の皆さまに向けて、各OSごとのバックポート対応方針とともにご紹介することで、できるだけ安心してnginxを使用していただけるようにしたいと思います。

少しでも皆様のお役に立てる記事にできればと思います。
どうぞよろしくお願い致します。

バックポートとは、本来は新しいソフトウェアのバージョンで修正された脆弱性やバグ修正の内容を、最新ではないバージョンのままのパッケージに後から移植（backport）して適用する手法を指します。

すなわち、OSによっては、新しいnginxバージョンで修正された脆弱性やバグ対応を独自パッチとして反映（バックポート対応）することで、古いnginxバージョンに対しても、一定のセキュリティレベルを事実上確保している場合があります。

ただし、このバックポート対応は、各OSベンダーが「危険」と判断した重要度の高い脆弱性（たとえば緊急や重要レベル）に限定して行われるのが一般的です。

また、どのnginxバージョンに、どの範囲まで適用するかはOSごとに方針が異なるため、EOL後のnginxバージョンに公式サポートと同等の脆弱性対策が継続されること意味しているわけではありません。

したがって、最新ではないnginxバージョンを使用している場合は、可能な限り現在利用中のOSベンダーがサポートするストリーム内で、修正済みの最新パッケージを適用することが推奨されることに変わりはありませんが、バックポート対応がされていれば、重要度の高い脆弱性については修正が反映されているため、一定の安心感を持って運用できるとは言えるかと思います。

Amazon Linux 2023のnginxパッケージでは、上流バージョンを維持したままセキュリティ修正を取り込むバックポート方式と、修正済みの新しい上流リリースへ更新する方式の両方が採用されています。
例えば、nginx 1.24.0では、上流バージョンを維持しながらAmazon Linux側のRelease番号を更新した修正版が複数提供されています。また、nginx 1.28系では、1.28.0を維持したまま修正を取り込んだ例と、修正済みの上流リリースである1.28.2へ更新した例の両方が確認できます。

Amazon Linux 2023では、脆弱性修正の優先順位は、まずAmazon Linuxが評価したSeverity（重要度）に基づいて判断されます。修正が利用者へ与える影響、必要なテスト、修正の複雑さなども、修正版のリリース時期を決定する際の判断材料となります。
nginxについて、「CVSS 7.0以上を必ず修正する」「一定以上のSeverityであれば必ずバックポートする」といった一律の基準は、ALAS FAQおよびAmazon Linux 2023のドキュメントでは示されていません。
また、脆弱性をバックポートで修正するか、修正済みの新しい上流リリースへ更新するかについても、明確な選定基準は示されていません。

このため、実運用では、CVSSスコアや上流のバージョン番号だけで修正状況を判断せず、Amazon Linux Security Centerで対象CVEのステータスを確認するとともに、発行済みのALASと、実際にインストールされているRPMのVersion・Releaseを照合することが重要です。ALASがまだ発行されていない場合でも、CVE ExplorerではPending Fix、No Fix Planned、Not Affectedなどの評価が公開されている場合があります。

RHEL（Red Hat Enterprise Linux）10及びその互換ディストリビューション（AlmaLinux OS 10、Rocky Linux 10）のnginxパッケージについては、Red Hatの一般的な更新方針として、上流の最新版へ全面的に更新するのではなく、既存のバージョン系列へセキュリティ修正を取り込むバックポート方式が基本となります（ただし、Red Hatは、十分な検証と分析を行ったうえで、一部のパッケージを新しい上流バージョンへ更新する場合もあると説明しています）。

RHEL 10では、nginx 1.26が2025年5月からFull Life Application Streamとして提供されており、RHEL 10のライフサイクルに沿って保守されます。これは、10年間まったく同じRPMパッケージに固定されるという意味ではなく、nginx 1.26系を基盤として、Red Hatのサポート方針に基づくセキュリティ更新や不具合修正が提供されることを意味します。
※RHEL 10 Full Life Application Streams Release Life Cycle参照
このため、nginx 1.26系統を使用されていたとしても、RHEL 10（ないしAlmaLinux OS 10、Rocky Linux 10）のnginxパッケージとして使用されている場合には、バックポート方式によって脆弱性が対応されている場合があります。

Red Hatが2025年4月1日以降の標準Errata基準として示しているセキュリティ修正の対象は、Red HatがCritical、ImportantまたはModerateと評価し、かつRed HatによるCVSSスコアが7以上のCVEです。ただし、すべてのErrataはRed Hatの裁量で提供されます（Lowに分類されたCVEは標準Errata基準には含まれていませんが、ほかの更新に修正が含まれる場合などもあるため、「Lowの脆弱性はバックポートされない」とは断定するものではありません）。
また、この基準はセキュリティErrataを提供する範囲に関するものであり、修正方法としてバックポートと上流バージョンの更新のどちらを選択するかを定める基準ではありません。

なお、AlmaLinux OS 10およびRocky Linux 10はRHEL 10との互換性を重視していますが、パッケージのビルド、公開時期、Errata、個別CVEのステータスは各ディストリビューションが管理しています。RHELのRHSAだけで対応済みと判断せず、AlmaLinuxでは同ディストリビューションのErrata、Rocky Linuxでは同ディストリビューションのアドバイザリと、実際に導入されているパッケージを確認してください。

RHEL（Red Hat Enterprise Linux）9及びその互換ディストリビューション（AlmaLinux OS 9、Rocky Linux 9）のnginxパッケージについても、RHEL 10と同様に、上流の最新版へ全面的に更新するのではなく、既存のバージョン系列へセキュリティ修正を取り込むバックポート方式が基本となります（十分な検証と分析を行ったうえで、一部のパッケージを新しい上流バージョンへ更新する場合もある点も同様です）。

RHEL 9のnginxパッケージについては、nginx 1.20が10年の長期固定ストリームとしてバックポート対応の対象となっており、nginx 1.22、1.24、1.26は2～3年間の短期ストリームとしてバックポート対応の対象となっています。
※RHEL 9 Full Life Application Streams Release Life Cycle参照
※RHEL 9 Application Streams Release Life Cycle参照
※nginx 1.22は2025年11月をもってバックポート対応が終了しました。
※バックポートの対象となる脆弱性については、RHEL 10と同様となります。

このため、nginx 1.20、1.24、1.26系統を使用されていたとしても、RHEL 9（ないしAlmaLinux OS 9、Rocky Linux 9）のnginxパッケージとして使用されている場合には、バックポート方式によって脆弱性が対応されている場合があります。

なお、AlmaLinux OS 9およびRocky Linux 9はRHEL 9との互換性を重視していますが、パッケージのビルド、公開時期、Errata、個別CVEのステータスは各ディストリビューションが管理しています。RHELのRHSAだけで対応済みと判断せず、AlmaLinuxでは同ディストリビューションのErrata、Rocky Linuxでは同ディストリビューションのアドバイザリと、実際に導入されているパッケージを確認してください。

RHEL（Red Hat Enterprise Linux）8及びその互換ディストリビューション（AlmaLinux OS 8、Rocky Linux 8）のnginxパッケージについても、RHEL 10と同様に、上流の最新版へ全面的に更新するのではなく、既存のバージョン系列へセキュリティ修正を取り込むバックポート方式が基本となります（十分な検証と分析を行ったうえで、一部のパッケージを新しい上流バージョンへ更新する場合もある点も同様です）。

RHEL 8のnginxパッケージについては、RHEL 10におけるnginx 1.26や、RHEL 9におけるnginx 1.20のような、長期固定ストリームを設定しておらず、nginx 1.14、1.16、1.18、1.20、1.22、1.24が2～3年間の短期ストリーム（1.24は5年間）としてバックポート対応の対象となっています。
※RHEL 8 Application Streams Release Life Cycle参照
※nginx 1.14、1.16、1.18、1.20はバックポート対応が終了しており、nginx 1.22も2025年11月をもってバックポート対応が終了しました。
※バックポートの対象となる脆弱性については、RHEL 10と同様となります。

このため、nginx 1.24系統を使用されていたとしても、RHEL 8（ないしAlmaLinux OS 8、Rocky Linux 8）のnginxパッケージとして使用されている場合には、バックポート方式によって脆弱性が対応されている場合があります。

なお、AlmaLinux OS 8およびRocky Linux 8はRHEL 8との互換性を重視していますが、パッケージのビルド、公開時期、Errata、個別CVEのステータスは各ディストリビューションが管理しています。RHELのRHSAだけで対応済みと判断せず、AlmaLinuxでは同ディストリビューションのErrata、Rocky Linuxでは同ディストリビューションのアドバイザリと、実際に導入されているパッケージを確認してください。

nginxの最新バージョンへのバージョンアップについては、Webアプリケーション側に不具合が発生する確率が高く、工数がかかることが予想されます。
この場合、不具合の原因を特定し、これを改修できる専門的な知識が必要です。

また、Web制作会社はいわゆるWebアプリケーション側（WebサイトやCMS等）を専門としていますので、nginxを含めたミドルウェアについては対応されていない会社も多いと思います。