IngressNightmare Returns: 3 New Injection Points and How to Keep Attackers Out

Introduction

When Wiz first disclosed IngressNightmare, they revealed a chain of vulnerabilities (CVE-2025-1097, CVE-2025-1098, CVE-2025-24514 and CVE-2025-1974) in the widely-used ingress-nginx controller for Kubernetes. They found that an unauthenticated attacker could escalate to full remote code execution inside the ingress-nginx pod, leading to compromise of Kubernetes clusters.

As part of our mission at Pentera Labs to help organizations understand and remediate new attack vectors, we set out to replicate these CVEs in our own lab. To our surprise, we quickly discovered three (!) additional injection points not covered in the original disclosure.

While Wiz’s team did an incredible job setting the stage with the initial heavy lifting, these new vulnerabilities reveal a different, and alarming, truth: not every attack path is known upfront. Once attackers are inside a network, a multitude of new possibilities for lateral movement and privilege escalation open up for them. And you can be sure they will explore and try to find them.

In this Pentera Labs research, we’ll explain how we identified three new undocumented injection points in ingress nginx. In the end, we’ll explain how to mitigate this risk and pitfalls to avoid when doing so.

The following article is an overview of our research. There is also a full research report that contains elaborate technical details and code about each step along the way and each identified vulnerability. The paper then explains how to detect vulnerability exposure in your own environments. 

Who should read this?

• Security researchers and red teamers – Engage in the exploration of novel attack and research techniques.
• Blue Teams – Ensure you can swiftly mitigate potential threats, validate your defenses against the vulnerabilities, and maintain robust security postures across the attack surfaces​​​​​​​​.
• DevOps – Understand the importance of secure Kubernetes practices, ensuring that your own operational practices will prevent similar vulnerabilities.
• CISOs – Stay informed about emerging threats and understand the potential risks to your organization.

Summary: 3 New Ingress Vulnerabilities Discovered

Building on Wiz’ research, Pentera Labs researchers discovered the following three injection points in ingress-nginx:

1. permanent-redirect annotation – Allows returning a permanent redirect instead of sending data to the upstream.
2. server-alias annotation – Allows the definition of one or more aliases in the server definition of the nginx configuration.
3. rewrite-target annotation – Allows rewriting the request path when the backend service expects a different URL than the Ingress path.

Kubernetes Disclosure and Response

At Pentera Labs, transparency, responsible disclosure, and contributing to a more secure ecosystem are core values. Upon discovering three previously undocumented injection points in the ingress-nginx controller, we responsibly disclosed our findings to the Kubernetes project team on April 22nd 2025. We also assured them that these vulnerabilities were effectively mitigated by the same patch (v1.12.1) originally issued for the Wiz-discovered flaws.

The Kubernetes team acknowledged our disclosure and asked for time to investigate. We have not received any further updates despite multiple follow-ups over nearly a month, and we informed them that we would proceed with publishing our findings on June 9th, unless advised otherwise.

We believe releasing this research is vital. While any organization that applied the v1.12.1 patch is protected from these vulnerabilities, many teams may still rely on mitigations alone, unaware of the additional injection points we identified. These organizations could remain vulnerable if they did not patch. Our goal is to ensure that defenders have full visibility into the scope of the risk and are empowered to act accordingly.

Does it apply to my organization?

If your organization uses a version of ingress-nginx earlier than 1.12.1, you may be affected by ingress-nginx vulnerabilities.

Impact of Ingress vulnerabilities

Hackers exploiting these vulnerabilities can result in applications exposed to open redirects, host header spoofing and path manipulation vulnerabilities. In insecure or multi-tenant environments, they may allow attackers to bypass routing rules, redirect users to malicious sites, or access unintended backend services.

Mitigations for IngressNightmare vulnerabilities

The best way to mitigate these vulnerabilities is to update your ingress-nginx to a newer version (1.12.1+). The injection vectors discovered by Wiz, along with the new ones we uncovered, have been patched in these later versions. So updating your nginx is enough to protect you from all the techniques we’ve demonstrated.

We’ve seen remediation recommendations that guide security teams to delete the validation webhook. This idea derives from the fact that these vulnerabilities rely on the admission webhook being exposed to the public.

We highly recommend refraining from doing so!

These webhooks enforce rules that prevent malformed or insecure resources such as dangerous Ingress configurations from being accepted by the API server. Without them, users can bypass critical safety checks, potentially leading to:

• Traffic misrouting
• Exposure of internal services
• Even a full cluster compromise.

In other words, admission objects won’t be verified, leaving your cluster at risk.

As mentioned, the recommended remediation option is to update ingress-nginx to version 1.12.1 and upwards.

What’s next for security teams

The IngressNightmare vulnerability chain serves as an important reminder that security isn’t just about patching CVEs. Rather, it’s about understanding how attackers think and continuously testing your environment accordingly. Attackers won’t stop at public disclosures. Once inside your environment, they’ll explore, experiment and exploit any configuration oversight. The discovery of these new vulnerabilities shows how easily a vulnerability can spiral into a full cluster compromise.

Read the full research article detailing all three vulnerabilities.

For more information, reach out to us at [email protected].