Red Hat Hardened Images で NGINX Rift に対応する

RHELのスペシャリストソリューションアーキテクトの田中司恩(@tnk4on)です。

nginx の rewrite モジュールにヒープバッファオーバーフローの脆弱性 CVE-2026-42945（通称「NGINX Rift」）が公開されました。Red Hat は本脆弱性の影響度（Impact）を Critical と評価しており（CVSS v3.1 Base Score: 8.1）、該当する全製品へのエラータを順次提供しています。脆弱性の詳細は CVE-2026-42945（Red Hat Customer Portal）、技術的な分析は NGINX Rift（depthfirst.com）、F5 のセキュリティーアドバイザリーは K000161019 を参照してください。

この記事では、コンテナーイメージとして nginx を利用している方に向けて、Red Hat Hardened Images の hi/nginx を使うことで NGINX Rift にいかに早く対応できるかを紹介します。前提として、アプリケーションがすでにコンテナー化されている、またはこれからコンテナー化を目指している環境を想定しています。Red Hat Hardened Images については、以前の記事「Red Hat Summit 2026で発表されたRHELの最新アップデート」でも紹介しています。

rheb.hatenablog.com

脆弱性対応の課題: パッチ適用までの時間

RHEL ユーザーにとって、脆弱性が公開されてからパッチを適用するまでの手順は通常、複数のステップにまたがります。Red Hat がエラータを公開し、リポジトリーの同期を行い、テスト環境で検証し、本番環境に適用する。以前の記事では Red Hat Satellite を使ってこのプロセスを効率化する方法を紹介しましたが、手順そのものが不要になるわけではありません。

コンテナー環境でも同様の課題があります。Docker Hub の公式 nginx イメージや UBI ベースの nginx イメージを使っている場合、アップストリームプロジェクトで脆弱性が修正されても、それがコンテナーイメージに反映されるまでには時間がかかります。イメージの更新を待ち、Containerfile を修正し、アプリケーションイメージを再ビルドし、テストしてデプロイする。この間、脆弱性スキャナーはアラートを出し続けますが、修正版のイメージが届かない限り、ユーザーは対処のしようがありません。あるいは、各ディストリビューションから修正済みのパッケージ（RHEL であれば RPM パッケージ）のみが先にリリースされている場合、そのパッケージをコンテナー内で適用し、イメージを再ビルドするという手順を自ら行う必要があります。

NGINX Rift は、こうした課題が特に注目されるケースとなりました。以前の記事で取り上げた CVE-2026-31431（Copy Fail）に続き、AI を活用した脆弱性検出が現実のものとなる中で発見された新たな Critical 脆弱性です。nginx はリバースプロキシーやロードバランサーとして広く使われており、Web インフラの入口に位置するコンポーネントであるため、他の脆弱性と組み合わされた場合の影響範囲が大きく、迅速な対応が求められます。このような状況で、Red Hat Hardened Images の hi/nginx はどれだけ速く修正版を届けることができたのでしょうか。

Red Hat Hardened Images カタログ（images.redhat.com）

hi/nginx の修正リリースはどれだけ速かったか

Red Hat Hardened Images の hi/nginx は、NGINX Rift の公開からわずか1日以内にエラータ RHSA-2026:17417 を発行し、修正版イメージをレジストリーに公開しました。

以下は CVE-2026-42945 に対する各製品のエラータ発行状況です（5/19 時点）。Red Hat Hardened Images が最も早く、5月14日に修正版をリリースしています。

製品	修正リリース日	CVE 公開からの日数
hi/nginx（Red Hat Hardened Images）	5/14	T+1
RHEL 9.2 AUS / E4S / ELS	5/15	T+2
RHEL 9.6 EUS（nginx:1.24 / nginx:1.26 モジュール）	5/15	T+2
RHEL 9.0 E4S / 9.4 EUS / 9.6 EUS / 10.0 EUS	5/16	T+3
RHEL 10 標準ストリーム（nginx）	Affected（5/19 時点で未修正）	—
RHEL 9 標準ストリーム（nginx:1.24 / nginx:1.26 モジュール）	Affected（5/19 時点で未修正）	—
Red Hat Lightspeed proxy 1	Affected（5/19 時点で未修正）	—

エラータの詳細は各 RHSA advisory ページの Affected Products セクションで確認できます*1。

hi/nginx は RHEL の EUS / AUS / E4S / ELS 各リポジトリーへのエラータ提供より1〜2日先行しており、RHEL 標準ストリーム（RHEL 9 / 10）には 5/19 時点でまだエラータが提供されていません。RHEL の各ストリームでは、パッケージのビルド・テスト・QE など複数のプロセスを経てエラータが発行されるため、提供までに時間がかかる場合があります。Red Hat Hardened Images はこのプロセスを自動化パイプラインで短縮しており、今回の NGINX Rift ではその差が顕著に現れました。

では、この速度はどのようにして実現されているのでしょうか。その鍵となるのが、アップストリームプロジェクトのコミットを自動検知し、RPM のビルドからコンテナーイメージの生成、レジストリーへの公開までを実行する自動化パイプラインです。Red Hat Hardened Images のパッケージには、Fedora dist-git をそのまま使う「clean」、Fedora に独自パッチを加える「modified」、Fedora に存在しないパッケージを独自に管理する「native」の3種類があり、参照するアップストリームが異なります。nginx は「clean」に分類されるため、Fedora メンテナのコミットがそのまま自動レーンに乗り、人手の介入なしで修正版がリリースされました*2。この仕組みにより、ユーザーは修正版のイメージが届くのを長く待つ必要がなくなります。

hi/nginx を使うとパッチ適用はどう変わるか

では、実際に hi/nginx を使っている場合、NGINX Rift への対応はどのように変わるのでしょうか。結論から言えば、コンテナーイメージを更新するだけで完了します。

従来のパッチ適用プロセスと比較してみましょう。

手順	従来の nginx イメージ	hi/nginx
修正版の提供を待つ	数日〜数週間	1日以内
Containerfile の修正	バージョンタグの変更が必要	フローティングタグなら変更不要
アプリケーションイメージの再ビルド	必要	必要
修正版の検証	SBOM なし、署名なしの場合が多い	SBOM・署名・来歴証明が標準付属

最も大きな違いは最初のステップです。修正版のイメージが届くまでの「待ち時間」が数日から1日以内に短縮されます。Red Hat Hardened Images のゼロ CVE 戦略により、脆弱性が公開されたらすぐに修正版のイメージが提供されるため、あとはイメージを pull してデプロイするだけです。

さらに、hi/nginx では :1 や :1.30 のようなフローティングタグが提供されています。これらのタグはメジャーバージョンやマイナーバージョン内の最新リリースを常に追跡するため、Containerfile を変更せずにイメージを再ビルドするだけでセキュリティー修正を取得できます*3。

Docker Hub や UBI の nginx イメージからの移行

まだ hi/nginx を使っていない場合でも、移行は容易です。多くの場合、Containerfile の FROM 行を書き換えるだけで動作します。

# Docker Hub の公式 nginx イメージを使っている場合
FROM docker.io/nginx:latest
# ↓
FROM registry.access.redhat.com/hi/nginx:1

メジャーバージョンタグ :1 を指定しておけば、nginx 1.x 系の最新セキュリティー修正が自動的に反映されます。Red Hat Developer の記事「Exploring distroless containers with Project Hummingbird」でも紹介されている通り、registry.access.redhat.com/hi/ というレジストリーパスを指定するだけで、Docker Hub のイメージとほぼ同じ使い勝手でコンテナーを起動できます。

$ podman pull registry.access.redhat.com/hi/nginx:1
$ podman run -d -p 8080:8080 registry.access.redhat.com/hi/nginx:1

移行にあたって知っておくべき違いがいくつかあります。以下の図と表で確認してみましょう。

項目	Docker Hub nginx	hi/nginx
リッスンポート	80	8080（非 root 実行のため）
実行ユーザー	root	UID 65532
シェル	あり（bash）	なし（distroless）
パッケージマネージャー	あり（apt）	なし
SBOM	なし	標準付属（SPDX 形式）
イメージ署名	なし	cosign + SLSA L3 provenance

ポート番号の変更（80 → 8080）は、Kubernetes のマニフェストや docker-compose.yml のポートマッピングを調整するだけで対応できます。シェルが含まれないため、コンテナー内部の調査には podman logs によるコンテナーログの確認や、一時的なデバッグコンテナーの使用が推奨されています。詳細は Red Hat Hardened Images の公式ドキュメントを参照してください。

なお、Containerfile でアプリケーション固有の設定をインストールしている場合や、ベースイメージに深い依存関係がある場合は、追加の調整が必要になることがあります。具体的な使い方や設定方法については、images.redhat.com の各イメージの Overview ページに掲載されています。

Red Hat Hardened Images は無償で利用可能です。登録やメールアドレスも不要で、images.redhat.com からすぐにダウンロードできます。

まとめ

この記事では、NGINX Rift（CVE-2026-42945）を題材に、Red Hat Hardened Images の hi/nginx を使うことでいかに早く脆弱性に対応できるかを紹介しました。

hi/nginx は CVE 公開から1日以内に修正版をリリースし、RHEL の各リポジトリーへのエラータ提供より1〜2日先行した
hi/nginx を使っている場合、パッチ適用はイメージを更新するだけで完了する
Docker Hub や UBI の nginx イメージからの移行は、多くの場合 FROM 行を書き換えるだけで導入できる

従来の RHEL パッチ運用では、Satellite のようなツールを使ってプロセスを効率化できますが、コンテナー化されたワークロードについては、Red Hat Hardened Images のゼロ CVE 戦略によってセキュリティー対応の速度を抜本的に引き上げることができます。すべてのワークロードを一度に移行する必要はありません。まずは nginx のような Web サーバーなど、セキュリティー上のインパクトが大きいコンポーネントから Red Hat Hardened Images への差し替えを検討してみてください。

リンク

*1:CVE ページの表は概要表示のため、1 errata あたり代表的な製品名が 1 行で表示されます。例えば RHSA-2026:17751 は CVE ページでは「RHEL 9.2 Update Services for SAP Solutions」と表示されますが、advisory ページには AUS / E4S / ELS の 3 系統・9 製品が列挙されています。

*2:実際のコミットログを追いたい方のために、主要なリンクを記載します。Fedora メンテナによる dist-git コミット: c423f5f5（2026-05-13 22:06 UTC）、Hummingbird rpms への自動 MR: 3140aa9f（2026-05-14 00:14 UTC）、自動マージ: df7ed5b5（00:51 UTC）、containers lockfile 更新: e2d1f8aa。

*3:Red Hat Hardened Images の公式ガイドでは、:latest タグはテスト用途向けとされています。本番環境ではメジャーバージョンタグ（:1）やマイナーバージョンタグ（:1.30）の使用が推奨されています。