The Kubernetes ecosystem has been rocked by the disclosure of four new critical vulnerabilities in the widely-used Ingress NGINX Controller, potentially enabling remote code execution (RCE) within affected clusters. These vulnerabilities — CVE-2025-1097, CVE-2025-1098, CVE-2025-24514, and CVE-2025-1974 — impact Ingress NGINX versions prior to v1.10.1, and together represent a powerful attack chain that can lead to full cluster compromise.

Ingress NGINX is one of the most commonly deployed ingress controllers in Kubernetes environments. It handles inbound traffic routing, SSL termination, and often sits directly at the edge of production systems — making it a high-value target. The newly discovered flaws demonstrate that even core, battle-tested Kubernetes components can introduce massive security risk when improperly configured or when their flexibility is exploited.

🔥 Summary of the Vulnerabilities

These four vulnerabilities, while distinct, have a cumulative effect: they can be chained or exploited in tandem to break through multiple layers of Kubernetes defenses. Here’s a deep dive into each.

1. CVE-2025-1097 – Arbitrary Command Injection via Annotations

This vulnerability allows unauthenticated remote attackers to inject operating system commands by crafting malicious Ingress annotations such as nginx.ingress.kubernetes.io/server-snippet, configuration-snippet, or proxy-snippet.

Root Cause:

Ingress NGINX supports advanced configurations via these annotations, which get injected directly into the final NGINX configuration file. If these values are not properly sanitized, an attacker could craft a configuration that includes shell escape sequences or embedded commands.

Exploitation Path:

Attacker creates or modifies an Ingress resource with a malicious snippet.
NGINX reloads configuration with injected code.
Payload executes in the controller’s container, leading to full RCE.

Impact:

An attacker can:

Execute shell commands on the controller pod.
Drop reverse shells or backdoors.
Pivot laterally within the Kubernetes cluster.
Exfiltrate secrets or access internal workloads.

2. CVE-2025-1098 – Arbitrary Lua Code Execution via Annotations

Lua scripting is a powerful feature in NGINX that supports dynamic logic for request processing. Ingress NGINX supports Lua through annotations like nginx.ingress.kubernetes.io/lua-snippet.

Root Cause:

Lua scripts provided via annotations are injected and evaluated dynamically during runtime. Without proper input validation, malicious Lua code can be executed within the NGINX context.

Exploitation Path:

Attacker includes malicious Lua logic in an Ingress annotation.
On processing an incoming HTTP request, the Lua code runs.
Code can manipulate traffic, extract data, or execute system calls.

Impact:

RCE inside the NGINX worker process.
Access to request/response payloads (e.g., headers, tokens).
Ability to modify traffic flow, exfiltrate data, or disrupt services.

3. CVE-2025-24514 – Admission Webhook Bypass

While not an RCE in itself, this CVE removes critical guardrails that prevent unsafe configurations. Admission webhooks are meant to inspect and validate Kubernetes API requests before they’re persisted. This flaw allows certain webhook protections to be circumvented.

Root Cause:

A logic flaw in request evaluation enables attackers to sneak in disallowed configurations (e.g., server-snippet or Lua code) by modifying Ingress resources in a specific order that avoids triggering webhook denials.

Exploitation Path:

Submit a benign Ingress resource that passes validation.
Modify it in a way that bypasses the webhook’s detection logic.
Inject malicious annotations post-validation.

Impact:

Attackers can introduce unsafe configurations without triggering policy blocks.
Enables exploitation of CVE-2025-1097 and CVE-2025-1098 even in hardened environments.

4. CVE-2025-1974 – Templating Injection in Custom Configurations

Ingress NGINX allows for custom templating logic using Go templates for dynamic NGINX configurations. This feature, when misused or left unguarded, enables attackers to inject unsafe template expressions that are evaluated at runtime.

Root Cause:

Improperly sanitized input in template configurations — such as custom error pages, headers, or rewrite rules — can lead to the execution of Go template functions that access file paths or environment variables.

Exploitation Path:

Attacker submits Ingress or ConfigMap with malicious template syntax.
Controller evaluates the template during reload or startup.
Arbitrary code or file reads occur.

Impact:

Local file disclosure (e.g., /etc/passwd, Kubernetes service account tokens).
Potential to read sensitive config files or secret mounts.
In advanced cases, template functions could be chained for execution of shell commands.

🎯 Who’s at Risk?

These vulnerabilities affect Ingress NGINX v1.10.0 and earlier, and environments with any of the following characteristics are at high risk:

Publicly exposed ingress controllers.
Clusters with multi-tenancy and weak isolation between users/namespaces.
Use of dynamic annotations (server-snippet, lua-snippet, custom-headers).
Weak RBAC policies that allow users or CI/CD pipelines to create or modify ingress resources.

🛡️ Mitigation and Recommendations

The Ingress NGINX project released v1.10.1 to address all four CVEs. Security teams should prioritize the following actions:

✅ Immediate Steps:

Upgrade to Ingress NGINX v1.10.1 or later.
Audit all Ingress resources for dangerous annotations like:
- server-snippet
- configuration-snippet
- lua-snippet
- custom-http-snippet
Search audit logs for suspicious modifications to Ingress resources.

🔐 Harden Your Cluster:

Disable risky annotation support unless explicitly required.
Use ValidatingAdmissionPolicies or OPA/Gatekeeper to block unsafe annotations.
Restrict RBAC permissions to prevent untrusted users from creating/modifying ingress.
Disable Lua modules if not needed.

🧪 Shift Left:

Implement static scanning of YAML manifests in CI/CD pipelines.
Use image signing and verification (e.g., Sigstore, Cosign) for controller images.
Validate Helm chart values and configurations before deployment.

📡 Monitor and Detect:

Deploy runtime monitoring (e.g., Falco, Tetragon) to detect:
- Unexpected command execution inside the ingress controller.
- Abnormal file reads or network activity from the pod.
Enable Kubernetes Audit Logs and alert on high-risk annotation usage.

🧠 Bigger Picture: Kubernetes Flexibility vs. Security

These vulnerabilities reveal a deeper issue: Kubernetes’ extensibility can become a liability when security isn’t baked in. Features like configuration snippets, templating, and embedded Lua provide incredible flexibility—but also create multiple paths to RCE if not guarded tightly.

The attack paths here required no zero-day kernel exploits, no container breakout, and no privilege escalation beyond what’s often granted by default. This is a stark reminder that application-layer vulnerabilities can be just as damaging as infrastructure flaws.

🔚 Final Thoughts

The discovery of CVE-2025-1097, CVE-2025-1098, CVE-2025-24514, and CVE-2025-1974 is a wake-up call. It highlights the importance of:

Treating ingress controllers as critical infrastructure.
Enforcing least privilege and least functionality.
Monitoring not just the network and host layers, but also Kubernetes-native behavior.

Organizations must proactively harden their Kubernetes environments—not just patch after a CVE drops. Because by the time a vulnerability is disclosed publicly, it may have already been exploited privately.