ingress-nginx rewrite-target nginx configuration injection

CVE-2026-3288 is a configuration injection in the nginx.ingress.kubernetes.io/rewrite-target handling path of ingress-nginx. The controller interpolates the Ingress spec.rules.http.paths.path value directly into a double-quoted nginx regex inside buildProxyPass() without escaping. A " character in the path closes the quoted string prematurely and the remainder is written into nginx.conf as raw directives — enough to load an arbitrary Lua block, exfiltrate the controller's ServiceAccount token, or shell out. Affected versions: ingress-nginx < 1.13.8, < 1.14.4, < 1.15.0. Fixed in 1.13.8 / 1.14.4 / 1.15.0, released 2026-03-04.

This is the *incomplete fix* to CVE-2026-24512. When maintainers introduced sanitizeQuotedRegex() in February 2026 to protect buildLocation(), they missed the identical sink in buildProxyPass(). The vendor's HIGH / 8.8 rating is accurate and arguably conservative — because the default ingress-nginx install ships a ClusterRole that can read Secrets *cluster-wide*, a successful injection turns any tenant with Ingress-write RBAC into a de facto cluster admin. In a shared/multi-tenant cluster the practical outcome is fleet-scale credential theft.

Why this verdict

• Role multiplier — ingress-nginx is infrastructure, not app tier: the default Helm install grants the controller SA secrets read cluster-wide. RCE in that pod = every Secret in the cluster, which means every ServiceAccount token, every TLS key, every cloud workload credential. Chain reliably ends in cluster-admin.
• Friction floor — PR:L is a low bar in multi-tenant clusters: most enterprise K8s clusters grant Ingress-write to project/namespace admins by default. In a shared cluster this is effectively tenant-to-cluster-admin escalation with a one-line YAML payload.
• Installed base is enormous: ingress-nginx is the most-deployed K8s ingress controller (~44% of clusters per Sysdig, ~340k internet-reachable instances per Censys). Even with PR:L gating, the reachable population is large.
• No downgrade for exposure: even air-gapped/private clusters are in scope — the attacker vector is a K8s API call, not an HTTP request to the ingress data plane. Firewalling the LB does not help.
• Not CRITICAL: no unauthenticated path, no KEV, no confirmed campaign, EPSS still under 10%. PR:L is meaningful enough to keep this out of the CRITICAL bucket for now.

Why not higher?

No unauthenticated remote path — the attacker must already have an authenticated Kubernetes identity with Ingress-write RBAC. No KEV listing and no confirmed mass-exploitation campaign as of 2026-07-02. EPSS remains under 10%. If a campaign emerges (Wiz/Sysdig telemetry begins showing post-exploitation Secret enumeration in the wild), this becomes CRITICAL immediately.

Why not lower?

MEDIUM would ignore the deployment-role floor: ingress-nginx *is* a canonical high-value component, cluster-wide Secret read is the shipped default, and a public PoC exists. Downgrading to MEDIUM would require evidence that the vast majority of installs restrict the controller ClusterRole and enforce admission policies on Ingress annotations — neither is the industry norm.

1. Deploy an admission policy blocking " in Ingress path fields and restricting rewrite-target — Ship a Kyverno or ValidatingAdmissionPolicy (K8s 1.30+) that rejects any Ingress whose spec.rules[].http.paths[].path contains a " character or whose nginx.ingress.kubernetes.io/rewrite-target annotation contains suspicious characters. Deploy across all clusters within the noisgate HIGH mitigation window — ≤ 30 days — as a bridge until every cluster is on 1.13.8/1.14.4/1.15.0.
2. Scope the ingress-nginx ClusterRole to namespaces you actually run Ingress in — The default install grants cluster-wide Secret read. Rewrite the ClusterRole to a set of RoleBindings scoped to the namespaces hosting Ingress resources. This does not prevent RCE in the controller pod but bounds the blast radius from *cluster-wide* to *scoped namespaces*. Roll out in the same 30-day mitigation window.
3. Audit and prune Ingress-write RBAC — Run kubectl auth can-i --list --as sweeps to enumerate every principal with create/update on ingresses. Remove access from CI service accounts, sandbox tenants, and low-trust developers. Do this before you deploy the patch — you'll want the pre/post delta for audit.
4. Enable runtime detection on the ingress-nginx controller pod — Add Falco/Sysdig/Aqua rules for: unexpected outbound HTTP from nginx worker, unexpected process spawn from nginx pid, and secrets list API calls from the ingress-nginx SA above baseline. Alerts here catch the post-injection stage even if admission control is bypassed.
5. Upgrade to 1.13.8 / 1.14.4 / 1.15.0 — Actual remediation. Bump the Helm chart (ingress-nginx-4.13.8+) or manifest to the fixed version. Because ingress-nginx is a data-plane component, use a rolling replacement and validate custom snippets still template correctly. Complete within the noisgate HIGH remediation window — ≤ 180 days, but prioritize toward the front of that window.

Run this on an auditor workstation with a kubeconfig that has read access to the target cluster (kubectl get pods -A should work). Invoke as ./check-cve-2026-3288.sh [context-name]. Reads the deployed ingress-nginx image tag and compares against fixed versions. Requires kubectl and jq.

#!/usr/bin/env bash
# noisgate verifier: CVE-2026-3288 (ingress-nginx rewrite-target injection)
# Exit: 0 PATCHED, 1 VULNERABLE, 2 UNKNOWN
set -u
CTX="${1:-}"
KUBECTL="kubectl"
[ -n "$CTX" ] && KUBECTL="kubectl --context=$CTX"

command -v jq >/dev/null || { echo "UNKNOWN: jq missing"; exit 2; }
command -v kubectl >/dev/null || { echo "UNKNOWN: kubectl missing"; exit 2; }

# Find any Deployment/DaemonSet running an ingress-nginx controller image
PODS=$($KUBECTL get pods -A -o json 2>/dev/null | \
  jq -r '.items[] | select(.spec.containers[]?.image | test("ingress-nginx/controller")) | \
    [.metadata.namespace, .metadata.name, (.spec.containers[] | select(.image|test("ingress-nginx/controller")) | .image)] | @tsv')

if [ -z "$PODS" ]; then
  echo "UNKNOWN: no ingress-nginx controller pods found in this cluster"
  exit 2
fi

vuln=0
unknown=0
while IFS=$'\t' read -r ns name image; do
  tag=$(echo "$image" | sed -E 's/.*:v?([0-9]+\.[0-9]+\.[0-9]+).*/\1/')
  if ! echo "$tag" | grep -qE '^[0-9]+\.[0-9]+\.[0-9]+$'; then
    echo "UNKNOWN: $ns/$name image=$image (cannot parse tag)"
    unknown=1
    continue
  fi
  IFS=. read -r maj min pat <<< "$tag"
  # Fixed: 1.13.8, 1.14.4, 1.15.0 (and any 1.15+ / 1.x >1.15)
  fixed=1
  if [ "$maj" -eq 1 ]; then
    if [ "$min" -lt 13 ]; then fixed=0
    elif [ "$min" -eq 13 ] && [ "$pat" -lt 8 ]; then fixed=0
    elif [ "$min" -eq 14 ] && [ "$pat" -lt 4 ]; then fixed=0
    fi
  elif [ "$maj" -lt 1 ]; then
    fixed=0
  fi
  if [ "$fixed" -eq 0 ]; then
    echo "VULNERABLE: $ns/$name running $tag"
    vuln=1
  else
    echo "PATCHED: $ns/$name running $tag"
  fi
done <<< "$PODS"

if [ "$vuln" -eq 1 ]; then exit 1; fi
if [ "$unknown" -eq 1 ]; then exit 2; fi
exit 0

Sources

1. Kubernetes issue #137560 — CVE-2026-3288
2. Kubernetes Security Advisory (discuss.kubernetes.io)
3. oss-security disclosure post
4. Sysdig — detecting CVE-2026-3288 & CVE-2026-24512
5. SnailSploit PoC and walkthrough
6. SnailSploit technical writeup
7. TheHackerWire — RCE and Secret Disclosure analysis
8. NVD entry