A tenant in a shared apartment building can flip the master breaker by editing the fuse box label
CVE-2026-116472 is a missing input-validation check in the mirror-target Ingress annotation in ingress-nginx. An attacker with permission to create Ingress objects can set this annotation to target the controller's own unauthenticated configuration API. The controller then writes attacker-controlled data into its routing configuration, corrupting it. All traffic through the shared ingress-nginx data plane is dropped until an Ingress change or controller restart rebuilds the config. All upstream ingress-nginx versions through the March 2026 maintenance end are affected; SUSE's fork is fixed in 1.15.2-prime1, and Kubernetes will not issue a fix.
The vendor rates this LOW (2.7) because CVSS uses PR:H and A:L. That undersells the real-world blast radius: in many clusters, developers hold create on ingresses in their namespaces, so the privilege is closer to low, and a successful write takes down every ingress served by that controller — a cluster-wide availability event on an edge component. The advisory's own note that traffic redirection is negligible doesn't change the DoS impact. We reassess as HIGH.
4 steps from start to impact.
Obtain Kubernetes Ingress create permission
- Kubernetes API access with RBAC verb create/update on ingresses in at least one watched namespace
- Target cluster uses a shared ingress-nginx controller across namespaces
- External remote attackers without valid Kubernetes credentials are blocked at this step
- Many enterprises restrict direct Ingress creation to GitOps pipelines, reducing the number of users with write access
Craft malicious mirror-target annotation
nginx.ingress.kubernetes.io/mirror-target annotation pointing to the controller's local unauthenticated configuration API. The annotation is processed without validation, so the target is accepted and later used by the controller.- Ability to apply an Ingress with arbitrary annotations
- Controller version vulnerable (all upstream ingress-nginx)
- The exact local config API endpoint may require knowledge of pod host/port, but the advisory implies it is reachable by the controller itself without special discovery
- Admission policies can be placed to reject mirror-target annotations targeting loopback/private ranges, though most clusters do not have one
mirror-target with loopback or API pathsController self-writes corrupt configuration
- Controller has network access to its own local config API (by design)
- The annotation value is accepted by the Ingress validation
- Missing validation is the root cause, so this step is low friction once the previous step is reached
Shared data plane outage
- Shared ingress-nginx controller serving multiple Ingresses/namespaces
- No immediate automated config reconciliation or health-check restart
- If ingress-nginx is deployed per-namespace or per-application, blast radius is limited to that hosted service
- A controller restart restores service, so the outage is recoverable but disruptive
mirror-target annotation contains 127.0.0.1, localhost, or the controller's config API. This breaks the attack before reconciliation. Deploy within 30 days (noisgate mitigation SLA for HIGH).create/update on Ingress resources; require GitOps or ticket-gated automation. This reduces the number of principals who can trigger the bug. Deploy within 30 days as a control.- Adding network firewalls or segmenting the data plane won't help: the attack flows through the Kubernetes API and the controller's own reconciliation loop, not through external ingress traffic.
- Disabling the
mirror-targetannotation at the controller level is not supported/effective unless paired with admission control; the missing validation is the bug. - Restarting ingress-nginx restores service but does not prevent repeated abuse; it is incident response, not mitigation.
The supporting signals.
| Product | Kubernetes ingress-nginx |
|---|---|
| CWE | CWE-20 Improper Input Validation |
| Disclosure date | 2026-11-05 |
| Affected versions | All upstream ingress-nginx versions through maintenance end (March 2026); SUSE/Rancher Prime RKE2 fork affected before 1.15.2-prime1 |
| Fixed versions | SUSE fork 1.15.2-prime1; upstream Kubernetes will not fix |
| KEV status | Not listed in CISA KEV |
| In-the-wild exploitation | No known exploitation; OffSeq Mirage recorded no attack traffic; no security vendor reports |
| Public PoC / exploit | None indexed on pocindex.io; VulDB reports no exploit; no Metasploit, Exploit-DB, or GitHub PoC found |
| EPSS | No EPSS data available; exploitation probability appears negligible |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:L (2.7 LOW) — PR:H disputed; in real clusters create Ingress is lower privilege |
Sources.
Why this verdict
- Low-privilege, cluster-wide DoS: a user who can create an Ingress can set
mirror-targetto the controller's local config API; the corrupted config drops all traffic through shared ingress-nginx. - Role multiplier: ingress-nginx is a canonical Kubernetes edge component; in shared clusters ≥10% of installs front multiple tenant workloads, so the blast radius is fleet-scale availability loss, not a single-host nuisance.
- Friction audit: requires valid Kubernetes API credentials and ingress
createpermission; no unauthenticated remote path, and no known exploit in the wild. - Vendor score mismatch: CVSS PR:H assumes high privilege, but many developers/CI tokens hold this permission; CVSS A:L undersells a full data-plane outage until restart.
Why not higher?
Not CRITICAL because the impact is availability-only and recoverable; no confidentiality, integrity, code execution, persistence, or domain compromise. A controller restart or Ingress change restores service, and the advisory states traffic redirection risk is negligible. Exploitation requires authenticated control-plane access, and there is no KEV listing or active exploitation evidence.
Why not lower?
Not MEDIUM/LOW because ingress-nginx sits on the edge and a single malicious Ingress takes down all ingress traffic across namespaces. The attack is low-complexity annotation injection with no patch for upstream ingress-nginx, and cross-tenant DoS in a shared cluster is a high-value availability event.
Crowdsourced verification payload.
Run on an auditor workstation with kubectl and a context containing get deployments permissions. Invoke ./check_cve-2026-116472.sh my-context. No cluster-admin is required, but cluster-wide read access to deployments is needed.
#!/bin/bash
# CVE-2026-116472 presence check for ingress-nginx
# Run from a workstation with kubectl context already configured.
# Usage: ./check_cve-2026-116472.sh [context]
set -euo pipefail
CONTEXT="${1:-}"
CTX_ARGS=()
if [ -n "$CONTEXT" ]; then CTX_ARGS=(--context "$CONTEXT"); fi
echo "[*] Searching for ingress-nginx deployments..."
DEPLOYS=$(kubectl "${CTX_ARGS[@]}" get deployments -A -o jsonpath='{range .items[*]}{.metadata.namespace}{" "}{.metadata.name}{" "}{.spec.template.spec.containers[*].image}{"\n"}{end}' 2>/dev/null || true)
if [ -z "$DEPLOYS" ]; then echo "UNKNOWN: unable to query deployments"; exit 2; fi
VULNERABLE_FOUND=0
FIXED_FOUND=0
while IFS= read -r line; do
ns=$(echo "$line" | awk '{print $1}')
name=$(echo "$line" | awk '{print $2}')
images=$(echo "$line" | cut -d' ' -f3-)
case "$images" in
*ingress-nginx*|*ingress-nginx-controller*)
if echo "$images" | grep -Eq '1\.15\.2-prime1'; then
echo "PATCHED: $ns/$name uses $images"
FIXED_FOUND=1
else
echo "VULNERABLE: $ns/$name uses $images (no SUSE 1.15.2-prime1 fix detected)"
VULNERABLE_FOUND=1
fi
;;
esac
done <<< "$DEPLOYS"
if [ "$VULNERABLE_FOUND" -eq 0 ] && [ "$FIXED_FOUND" -eq 0 ]; then
echo "PATCHED: no ingress-nginx deployment found; cluster not affected"
exit 0
elif [ "$VULNERABLE_FOUND" -eq 1 ]; then
echo "Overall: VULNERABLE"
exit 1
else
echo "Overall: PATCHED"
exit 0
fi