Kubernetes►Security

Critical Ingress-NGINX Vulnerabilities in Kubernetes: What You Need to Know

In the fast-moving world of Kubernetes security, misconfigurations and overlooked edge cases can expose entire clusters to serious risk. Recently, researchers from Wiz uncovered a set of high-impact vulnerabilities in the widely-used Ingress-NGINX controller—vulnerabilities that could allow attackers to bypass security controls, steal credentials, or take over workloads in multi-tenant environments.

Here’s a breakdown of what happened, what it means, and how to protect your clusters.

The TL;DR

  • Vulnerabilities Found: Wiz disclosed multiple vulnerabilities in Ingress-NGINX, the most popular Kubernetes ingress controller.
  • Impact: Attackers could exploit these flaws to:
    • Inject arbitrary code via annotations
    • Escalate privileges across namespaces
    • Access sensitive services or data
  • Root Cause: Insufficient validation of user-supplied annotations and their interpretation in the NGINX configuration.

Background

Ingress-NGINX is the default ingress controller for many Kubernetes deployments. It provides a way to expose HTTP and HTTPS services to the outside world, route traffic, enforce SSL, and handle complex routing logic.

What makes this controller powerful—its flexibility through annotations—also introduces risk when those annotations are not properly validated.

The Vulnerability

Wiz discovered that certain annotations could be crafted in ways that trick Ingress-NGINX into injecting unsanitized configuration blocks directly into its internal NGINX configuration.

Specifically, the vulnerability stems from the nginx.ingress.kubernetes.io/server-snippet and related annotations. If these are not restricted at the admission level, users could inject arbitrary NGINX directives, effectively allowing:

  • Unauthorized access to internal services
  • Bypass of security policies
  • Data exfiltration

In multi-tenant environments where untrusted users can define Ingress resources, this becomes a serious privilege escalation vector.

Real-World Impact

The issue becomes particularly dangerous in shared Kubernetes environments, such as:

  • Internal developer platforms
  • Multi-team CI/CD environments
  • Kubernetes platforms offered by managed service providers

An attacker with permission to create or edit an Ingress resource could craft malicious annotations and compromise the entire cluster.

What You Should Do

The Wiz team coordinated disclosure with the maintainers, and patches are now available. Here’s how to protect your environments:

  1. Upgrade to the latest Ingress-NGINX release
    Ensure you’re running a version with the vulnerability patched. Review the Ingress-NGINX changelog for details.

  2. Audit and restrict annotation usage
    Limit the use of dangerous annotations (like server-snippet, configuration-snippet, and proxy-snippet) by applying admission controls or policies.

  3. Enforce namespace boundaries
    Use Kubernetes RBAC and tools like OPA/Gatekeeper or Kyverno to ensure that users in one namespace can’t affect others.

  4. Monitor for suspicious Ingress definitions
    Integrate cluster monitoring tools that can alert on new Ingress resources using unusual annotations.

Final Thoughts

This disclosure is a critical reminder that flexibility in configuration must be matched with rigorous security controls. Ingress controllers operate at the gateway of your cluster—they must be hardened, monitored, and tightly controlled.

If you’re managing Kubernetes in a multi-tenant or high-security environment, now is the time to review your use of Ingress-NGINX and lock down risky paths.

For more technical details, check out the original write-up by Wiz.

Stay secure,
Duo