GPU VulnDB

Database/Container, Kubernetes & orchestration

NGINX Ingress Controller: unsanitized Ingress annotations inject arbitrary NGINX directives

CVE-2026-77180Container, Kubernetes & orchestrationcurated

Impact

Any principal with Kubernetes RBAC to create or edit Ingress objects in a namespace the controller serves can write arbitrary directives into the generated nginx.conf, because multiple annotation fields are interpolated without sanitization. F5 states this reaches file creation and deletion and service disruption inside the controller, and is control-plane only with no data-plane exposure. In a multi-tenant GPU cluster, Ingress write is routinely delegated per namespace or per team, so this crosses the tenant-to-ingress boundary. The ingress controller fronts every model endpoint on the cluster, so losing it takes inference serving offline fleet-wide while the GPUs themselves stay healthy.

Who can reach it

Authenticated Kubernetes user or service account holding create/update on Ingress resources through the API server. No cluster-admin rights and no access to the data plane are needed.

What to do

Deploy the fixed NGINX Ingress Controller release identified in F5 K000162601 and roll the ingress pods; a rolling restart briefly interrupts new connection setup and no GPU nodes are touched. Note that F5 does not evaluate versions past End of Technical Support, so an EoTS deployment has to be upgraded off that branch rather than patched. Until the upgrade lands, restrict who can write Ingress annotations through RBAC or an admission policy that rejects unexpected annotation keys.

References

Related entries

All Container, Kubernetes & orchestration entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.