
Falco Feedsは、オープンソースに焦点を当てた企業に、新しい脅威が発見されると継続的に更新される専門家が作成したルールにアクセスできるようにすることで、Falcoの力を拡大します。

本文の内容は、2026年3月17日にMichael Clark が投稿したブログ(https://www.sysdig.com/blog/detecting-cve-2026-3288-cve-2026-24512-ingress-nginx-configuration-injection-vulnerabilities-for-kubernetes)を元に日本語に翻訳・再構成した内容となっております。
2026年3月9日、Kubernetesのingress-nginxプロジェクトは、NGINX Ingress Controllerにおける設定インジェクションの脆弱性であるCVE-2026-3288(CVSS 8.8 HIGH)の修正をマージしました。この脆弱性は、Ingressのパスフィールドにダブルクォーテーション文字(”)を挿入することで、Ingressリソースを作成または変更する権限を持つ任意のユーザーに悪用される可能性があります。このフィールドは入力を適切にサニタイズしていないため、攻撃者は引用符によって想定された構文を破壊し、生成される設定内に任意のnginx設定ディレクティブを注入することが可能です。公式アドバイザリーによると、この脆弱性はリモートコード実行(RCE)や、コントローラがアクセス可能なシークレットの漏洩につながる可能性があります。
CVE-2026-3288は、1か月前に修正されたパスインジェクションの脆弱性であるCVE-2026-24512とも密接に関連しています。CVE-2026-24512の修正ではsanitizeQuotedRegex()関数が導入され、buildLocation()に適用されましたが、buildProxyPass()には適用されなかったため、rewriteディレクティブが同様のインジェクションの影響を受ける状態のままとなっていました。これらの脆弱性は、ingress-nginxにおける一連のセキュリティ課題の最新事例であり、これが月末に予定されているプロジェクトの終了を招く一因となっています。
Sysdig 脅威リサーチチーム(TRT)は、両CVEの根本原因を分析し、Kubernetesの監査ログを通じた悪用試行を検知するFalcoルールを作成しました。これらの脆弱性に関するSysdig TRTの詳細な分析と調査結果は以下の通りです。
影響を受けるバージョン
- 影響あり:NGINX Ingress Controllerのv1.13.8、v1.14.4、v1.15.0より前のバージョン
- 修正済み:v1.13.8、v1.14.4、v1.15.0(2026年3月9日リリース)
- 修正コミット:PR #14667
- 関連:CVE-2026-24512(buildLocation()を介したパスインジェクション、PR #14501によりv1.13.7およびv1.14.3で修正)
根本原因:サニタイズの欠如
NGINX Ingress Controllerは、KubernetesのIngressオブジェクトをnginxの設定に変換します。Ingressにrewrite-targetアノテーションが含まれている場合、コントローラはtemplate.go内のbuildProxyPass()関数を通じて、対応するlocationブロック内にrewriteディレクティブを生成します。以下に示す通りです:
return fmt.Sprintf(`
rewrite "(?i)%s" %s break;
%v%v %s%s;`, path, location.Rewrite.Target, xForwardedPrefix, proxyPass, proto, upstreamName)path変数は、Ingressのspec.rules.http.paths.pathフィールドから直接取得され、エスケープ処理が行われないままダブルクォーテーションで囲まれたnginxの文字列に埋め込まれます。pathに(”)文字が含まれている場合、引用された正規表現が途中で閉じられ、それ以降の内容が生のnginx設定として解釈されます。
関連する関数であるbuildLocation()は、CVE-2026-24512の一環として1か月前に修正されました。この修正(PR #14501)では、\および”文字をエスケープするsanitizeQuotedRegex()関数が導入され、buildLocation()に適用されました:
func buildLocation(input interface{}, enforceRegex bool) string {
path := sanitizeQuotedRegex(location.Path)
if enforceRegex {
return fmt.Sprintf(`~* "^%s"`, path)
}
// ...
}しかし、同じ修正はbuildProxyPass()には適用されませんでした。PR #14667におけるCVE-2026-3288の修正では、buildProxyPass()にも同様にsanitizeQuotedRegex()の呼び出しが追加されています。これは任意コード実行の欠陥を回避するための1行の変更です。
インスペクターの回避
NGINX Ingress Controllerには、Ingressオブジェクトを処理する前に検証するDeepInspect関数が含まれています。このインスペクターは各パスをCheckRegexに通し、既知の危険なnginxディレクティブのブロックリストと照合します:
invalidAliasDirective = regexp.MustCompile(`(?s)\s*alias\s*.*;`)
invalidRootDirective = regexp.MustCompile(`(?s)\s*root\s*.*;`)
invalidEtcDir = regexp.MustCompile(`/etc/(passwd|shadow|group|nginx|ingress-controller)`)
invalidSecretsDir = regexp.MustCompile(`/var/run/secrets`)
invalidByLuaDirective = regexp.MustCompile(`.*_by_lua.*`)このブロックリストは不完全です。return、set、try_filesといったディレクティブはチェックされず、エラーなしで通過します。私たちは、returnがインスペクターを回避し、インジェクションされたペイロードとともに正常に実行されることを確認しました。
さらに、このインスペクターは英数字のみのパスを強制するvalidPathTypeという正規表現を定義しています:
validPathType = regexp.MustCompile((?i)^/[[:alnum:]._\-/]*$)
この正規表現は一度も呼び出されていません。つまりデッドコードとして存在しており、インスペクターは(”)、(、)、(;)、スペース、#、およびその他の特殊文字を含むパスを制限なく受け入れてしまいます。
エクスプロイテーション(悪用方法)
前提条件
攻撃者は、脆弱なNGINX Ingress Controllerが稼働しているクラスター内の任意のネームスペースで、Ingressリソースを作成または変更する権限を持っている必要があります。
インパクト
公式アドバイザリーによると、この脆弱性は任意のコード実行や、コントローラがアクセス可能なシークレットの漏洩につながる可能性があります。デフォルトのインストールでは、NGINX Ingress Controllerはクラスター全体のすべてのシークレットにアクセスできます。インスペクターのブロックリストは、includeやssl_engineといったディレクティブをカバーしておらず、これらは私たちがテストした範囲を超えて、コード実行やファイルの漏洩につながる可能性があります。
テストの過程で、Sysdig TRTは、インスペクターがブロックしないreturnディレクティブを使用して、以下の攻撃シナリオが可能であることを確認しました:
- 任意のパスで攻撃者が制御するコンテンツを配信することでレスポンスを乗っ取る。
- ユーザーをフィッシングページや認証情報収集サイトへリダイレクトする。
- $http_authorizationなどのnginx変数を使用して、Bearerトークン、APIキー、Basic認証情報をレスポンスボディに反映させることで認証情報を窃取する。
- $server_addrなどのnginx変数を返すことで、コントローラPodの内部IPアドレスを露出させ、内部状態を漏洩させる。
- nginxのリロードを妨げる無効な設定を注入することでサービス拒否を引き起こす。
Sysdig 脅威インテリジェンス
この脆弱性の検知はSysdig SecureのThreat Intelligenceページに追加されており、「Home → Threat Intelligence」からアクセスするか、「Remote Code Execution Vulnerabilities in NGINX Ingress Controller」で検索することで確認できます。

Falcoによる検出
以下のFalcoルールは、Kubernetesの監査ログデータを使用して、パスにダブルクォーテーションを含むIngressリソースの作成または変更を検知します:
rule: Ingress-NGINX Path Configuration Injection
desc: >
Detects Kubernetes Ingress resources where the path field contains a
double-quote character, indicating potential ingress-nginx configuration
injection via CVE-2026-3288 (buildProxyPass) or CVE-2026-24512
(buildLocation). Both vulnerabilities use the path field as the
injection vector.
condition: >
kevt and ingress and kmodify and response_successful
and jevt.value[/requestObject/spec/rules/0/http/paths/0/path] contains "\""
output: >
Suspicious ingress path with config injection characters detected -
possible CVE-2026-3288 / CVE-2026-24512
(user=%ka.user.name
verb=%ka.verb
ingress=%ka.target.name
ns=%ka.target.namespace
path=%jevt.value[/requestObject/spec/rules/0/http/paths/0/path])
priority: CRITICAL
source: k8s_audit
tags: [k8s, cve-2026-3288, cve-2026-24512, ingress-nginx, config-injection]
CVE-2026-3288およびCVE-2026-24512はいずれも、Ingressのパスフィールドに(”)文字を必要としますが、これは正当なIngress定義には決して含まれません。そのため、単一のルールで両方の脆弱性をカバーできる、高精度な検知シグナルとなります。
Sysdig Secureのお客様は、Sysdig K8s Notable EventsにおけるIngress-NGINX Malicious AnnotationまたはPath Injectionによって自動的に保護されており、質問がある場合は各ユーザーのSysdigアカウントチームに問い合わせてください。
検知の仕組み
SysdigおよびFalcoは、正常に完了したIngressの作成、更新、またはパッチ操作(kmodify)(response_successful)に関するKubernetesの監査イベントを監視します。その後、jevt.value[/requestObject/spec/rules/0/http/paths/0/path]を使用して生のリクエストボディを検査し、Ingress仕様内の最初のHTTPパスからpathの値を抽出します。この値に(”)文字が含まれている場合、検知はアラートを送信します。
検証中に、同一クラスター上に正常なIngress(path: /app)とエクスプロイト用Ingressの両方をデプロイしました。その結果、アラートは作成および更新操作においてエクスプロイト用Ingressに対してのみ発報され、正常なリソースに対する誤検知はゼロでした。
推奨事項
- ingress-nginxをv1.13.8、v1.14.4、またはv1.15.0に更新してください。これらにはbuildProxyPass()におけるsanitizeQuotedRegex()の修正が含まれています。
- 上記のFalcoルールをデプロイし、Kubernetesの監査ログを通じた悪用試行を検知してください。
- ロールベースのアクセス制御(RBAC)を使用してIngressの作成権限を制限し、どのユーザーおよびサービスアカウントがIngressリソースを作成または変更できるかを限定してください。
- ingress-nginxのアドミッションWebhookが有効であることを確認してください(Helmチャートではデフォルトで有効です)。これは生成された設定に対してnginx -tを実行し、無効な設定を生成するIngressオブジェクトを拒否します。
- 特殊文字を含むパスが存在するか、既存のIngressリソースを監査してください:kubectl get ingress -A -o json | jq ‘.items[].spec.rules[].http.paths[].path’ | grep ‘[”;\#]’。
- 「received invalid ingress」というメッセージが出力されていないかNGINX Ingress Controllerのログを監視してください。これはインスペクターが潜在的に悪意のあるIngressを拒否したことを示します。
緩和策
複数の防御層により、本番環境において悪用が成功する可能性は低減されます。
- これはインターネットに直接公開された脆弱性ではありません。攻撃者はKubernetes APIに対して認証されており、Ingressリソースを作成または変更する権限を持っている必要があります。最も現実的な脅威は、侵害されたCI/CDパイプラインや、ネームスペースレベルのアクセス権を持つ悪意のある内部関係者です。
- アドミッションWebhookは一部のペイロードを検出します。ingress-nginxのHelmチャートではデフォルトでアドミッションWebhookが有効になっており、Ingressを受け入れる前に生成されたnginx設定を検証します。テスト中、エクスプロイトをデプロイするためにWebhookを削除する必要がありました。しかし、(return 200のように)有効なnginx構文を生成するペイロードはこのチェックを通過し、ブロックされません。
- 2つ目のサニタイズ関数は、新しいバージョンにおいて到達可能性を制限します。v1.13.7またはv1.14.3(CVE-2026-24512の修正が適用されている)を実行しているクラスターでは、関連する関数buildLocation()がパスを正しくエスケープし、通常のHTTPリクエストでは一致しないlocationの正規表現を生成します。注入されたディレクティブはnginx設定内に存在しますが、トリガーされることはありません。しかし、buildLocation()もサニタイズされていない古いバージョンを使用している組織では、locationの正規表現が一致可能であり、注入されたコードはHTTPリクエストを通じて直接到達可能となります。
まとめ
CVE-2026-3288は、CVE-2026-24512に対する不完全な修正に起因する設定インジェクションの脆弱性です。2026年2月にbuildLocation()を保護するためにsanitizeQuotedRegex()が導入された際、同じサニタイズ処理がbuildProxyPass()には適用されず、rewriteディレクティブが同様のパスインジェクションの影響を受ける状態のままとなりました。既知の危険なディレクティブのブロックリストに依存するインスペクターと、一度も呼び出されないデッドコードの検証処理が組み合わさることで、広範なインジェクションペイロードが検知されることなく通過してしまいます。
この脆弱性は、CVE-2026-24512(buildLocation()を介したパスインジェクション)、CVE-2021-25742(スニペットインジェクション)、CVE-2024-7646(\rを介したアノテーションベースのインジェクション)など、これまでのingress-nginxにおける設定インジェクションのCVEで見られたパターンに従っています。これらの事例はいずれも、ユーザー制御の入力をnginxの設定テンプレートに安全に埋め込むことの難しさを示しています。
ingress-nginxを使用している組織は、v1.14.4以降へのアップデートを優先し、即時のパッチ適用が難しい環境においては、悪用の試行を検知するためにSysdig SecureまたはFalcoの検知ルールを導入する必要があります。