ingress-nginxは、Kubernetesクラスタの外部からのHTTP/HTTPS通信を制御するIngressコントローラとして、長く事実上の標準だった。この開発が2026年3月24日、GitHubリポジトリのアーカイブという形で正式に終わった。退役表明の直後、2026年2月に4件のHIGH〜LOW深刻度の脆弱性が開示され、いずれも1.13.7と1.14.3で修正された。しかしこれが最後の修正版になる。今後どんな脆弱性が見つかっても、開発元からの修正は二度と提供されない。問題は、この事実を知らないまま古いバージョンを使い続けるクラスタが少なくないことだ。本稿では、退役直前に開示された4件のCVEの中身と、移行未完了クラスタが抱える実際のリスク、そして移行先の選び方を整理する。
予備知識
- Ingress: クラスタ外部からのHTTP/HTTPSトラフィックを、内部のServiceへ振り分けるAPIリソース。
- Ingressコントローラ: Ingressリソースを実際のルーティング設定に変換するソフトウェア本体。ingress-nginxはその代表例。
- HIGH深刻度: CVSS（共通脆弱性評価システム）の区分の一つ。v3系ではスコア7.0〜8.9がHIGH、9.0以上がCRITICAL。
- Gateway API: IngressAPIの後継として設計された、Kubernetesの公式トラフィック制御標準。GatewayとHTTPRouteに役割を分割する。
Ingressの仕組みを体系的に理解し、移行先のGateway API実装を評価する土台を作れる定番書
ingress-nginxはなぜ退役し、いつリポジトリが閉じたのか
ここでいう退役とは、Kubernetesプロジェクト配下でのメンテナンスが完全に終了し、以後は誰も公式に開発しない状態を指す。Kubernetes運営委員会とセキュリティ対応委員会は、2026年1月29日付のブログ記事で、ingress-nginxプロジェクトの退役を正式に発表した[1]。同記事は「2026年3月以降、Ingress NGINXの新しいリリースもバグ修正もセキュリティ更新も一切提供されない」と明記した[1][2]。この発表から数日後の2026年2月2日、退役前最後の修正としてCVE-2026-1580、CVE-2026-24512、CVE-2026-24513、CVE-2026-24514の4件が開示された[2]。修正版は1.13.7と1.14.3として公開され、この2バージョンが事実上の最終リリースになった[3]。2026年3月24日、GitHubのkubernetes/ingress-nginxリポジトリはアーカイブされ、読み取り専用になった[6]。Issueの新規作成もプルリクエストのマージもできない状態が続いている[6]。ingress-nginxはクラウドネイティブ環境のおよそ半数で稼働しているとされ、影響範囲は一部の先進的な利用者にとどまらない[2]。
コンテナ環境で繰り返し起きるリスクのパターンを学び、放置クラスタの棚卸し観点を養える一冊
未修正のまま残る4件のCVEはどれほど深刻か
ここでは、開示された4件の脆弱性がどのバージョンに影響し、どの操作で攻撃が成立するかを整理する。4件はいずれも1.13.7と1.14.3より前の全バージョンに影響する[3][4][5]。CVE-2026-1580は、auth-method向けのIngressアノテーションを悪用してnginx設定に任意のコードを注入できる欠陥で、CVSSスコアは8.8のHIGHにあたる[3]。CVE-2026-24512は、Ingressのrules.http.paths.pathフィールドを経由して同様の設定注入を許し、こちらもCVSS8.8のHIGH[4][8]。両者とも成功すればingress-nginxコントローラの権限でコードが実行され、既定構成ではクラスタ全体のSecretにアクセスできる[3][4]。CVE-2026-24514は、Admission Webhookに巨大なAdmissionReviewオブジェクトを送りメモリを枯渇させるサービス拒否で、CVSS6.5のMEDIUM[5]。CVE-2026-24513は、auth-urlアノテーションによる認証保護が、バックエンドがX-Codeヘッダーを尊重しない特定の誤設定下で回避されうる欠陥で、CVSS3.1のLOWにとどまる[9]。
| CVE番号 | CVSS (v3.1) | 深刻度 | 内容 |
|---|---|---|---|
| CVE-2026-1580 | 8.8 | HIGH | auth-methodアノテーション経由のnginx設定注入・コード実行 |
| CVE-2026-24512 | 8.8 | HIGH | rules.http.paths.path経由のnginx設定注入・コード実行 |
| CVE-2026-24514 | 6.5 | MEDIUM | Admission WebhookへのDoS（メモリ枯渇） |
| CVE-2026-24513 | 3.1 | LOW | auth-url保護の誤設定下でのバイパス |
2件がHIGHでコード実行に直結する点は見過ごせない。これらは1.13.7/1.14.3へ更新済みなら塞がれているが、退役後に新たに見つかる脆弱性は、深刻度を問わず今後永久に修正されない[1][2]。
コンテナランタイム（コンテナを実際に起動・管理するソフトウェア）レイヤーで、見落としがちな断絶系アップグレードが進行している。Kubernetes 1.36（2026年4月22日リリース）はcgroup v1（Linuxのリソース制[…]
移行先はどう選ぶか——Gateway APIが軸になる
ここでは、Kubernetesプロジェクトが後継として何を推しているかを整理する。Kubernetesプロジェクトは、ingress-nginxの直接的な後継製品を指定していない[1]。代わりに、IngressAPIの後継として設計されたGateway APIへの移行を推奨している[1][2]。Gateway APIはL4/L7ルーティングを扱うKubernetes公式仕様で、GatewayとHTTPRouteという複数リソースに設定を分割する構造を持つ[2]。
Gateway API準拠のコントローラ実装は複数存在し、性能要件やチーム規模によって向き不向きが分かれる。Envoy Gatewayは、Envoyをベースにした軽量な実装で、mTLSやJWT検証を単体で扱える[10]。HAProxy Kubernetes Gatewayは低レイテンシ用途向け、Traefikは小中規模クラスタでの運用しやすさが特徴とされる[10]。NGINX Gateway Fabricは、NGINX社自身が示すingress-nginxの後継で、Gateway APIネイティブに設計されている[10]。Kong Kubernetes GatewayはOAuth2やWASM拡張などエンタープライズ向け機能を備える[10]。いずれもIngressリソースからの単純な置き換えではなく、ルーティング定義自体をHTTPRouteへ書き直す作業を伴う[2][10]。
2026年7月14日、イベント駆動アーキテクチャの仕様記述に使われるOSS標準「AsyncAPI」がnpm（JavaScriptの標準パッケージレジストリ）で配布する4パッケージ5バージョンに、悪性コードが混入していたことが判明した[1][…]
移行未完了クラスタが今すぐ着手すべき棚卸し
ここでは、移行判断の前に何を確認すべきかを具体的に示す。第一歩は、自組織のクラスタでingress-nginxが実際に稼働しているかの確認である。Helmリリースやコンテナイメージ名で検索し、稼働バージョンを一覧化する[6]。バージョンが1.13.7または1.14.3より古ければ、4件のCVEすべてに継続的に露出している状態にあると判断する[3][4][5][9]。すでに1.13.7/1.14.3以降であっても、退役後は新規CVEへの対応が二度と来ない前提で移行計画を立てる必要がある[1][2]。移行計画では、既存のIngressリソースが使っているアノテーション（auth-url、auth-method、rewrite-targetなど）を棚卸しし、移行先のGateway API実装がそれぞれ同等の機能を持つかを個別に確認する作業が欠かせない[2][10]。この確認作業を後回しにするほど、放置クラスタは増え、退役という既定事実だけが積み上がっていく。
⚠️ 結論：Sora 2（OpenAI）は提供終了しました Web版・アプリ版：2026年4月26日に提供終了（OpenAI公式ヘルプの案内）。 API：2026年9月24日に終了予定。 これ[…]
よくある質問（FAQ）
Q1. ingress-nginxはもう使えなくなったのですか。
A. 既存のHelmチャートやコンテナイメージは引き続き入手できるため、稼働自体は止まらない。ただし2026年3月24日のリポジトリアーカイブ以降、開発元による新規リリースやセキュリティ修正は提供されない[1][6]。
Q2. 4件のCVEはもう修正されているのですか。
A. 1.13.7と1.14.3で修正済みだが、この2バージョンが最終リリースになった。それより古いバージョンを使い続けるクラスタは、4件に恒久的に露出したままになる[3][4][5][9]。
Q3. 移行先は何を選べばよいですか。
A. Kubernetesプロジェクトは特定製品ではなくGateway APIへの移行を推奨している。Envoy Gateway、Traefik、NGINX Gateway Fabricなど複数の準拠実装から選ぶ形になる[1][2][10]。
まとめ
ingress-nginxは2026年3月24日にリポジトリがアーカイブされ、開発が完全に終了した。退役直前の2026年2月に開示された4件のCVEのうち2件はCVSS8.8のHIGHでコード実行に直結し、1.13.7/1.14.3で修正済みだがそれが最後の修正になった。読者が取るべき行動は明確である。自クラスタでのingress-nginx利用有無とバージョンを棚卸しし、古いままなら4件のCVEへの露出を認識したうえで、Gateway API準拠の移行先候補の選定に着手する。退役という既定路線が変わることはない以上、対応の先送りは露出期間をただ伸ばすだけになる。
