Ingress-nginx-controller: Nightmare on CVE Street

On March 24th, 2025 it was reported by Wiz Research that several remote code execution CVEs were affecting the Ingress-nginx-controller. These CVEs were detailed in security advisories by the Kubernetes team, and the attack vector was given a CVSS base score of 9.8, highlighting their severity. These vulnerabilities allowed attackers to exploit weaknesses in the ingress controller and gain unauthorized access to all the secrets stored across all the namespaces in a Kubernetes cluster. In the worst case scenario, these CVEs would allow a bad actor to completely take over a kubernetes cluster.

Here’s the breakdown of CVEs:

1. CVE-2025-24513:This vulnerability involves improper handling of specific ingress configurations, which may lead to unauthorized access or manipulation of internal services.

2. CVE-2025-24514: This flaw could result in a potential denial of service (DoS) by exploiting weaknesses in the way traffic is handled, leading to an interruption in service availability.

3. CVE-2025-1097: An issue with input validation in ingress-nginx-controller that could lead to privilege escalation, potentially allowing attackers to gain unauthorized elevated permissions.

4. CVE-2025-1098:This vulnerability could allow an attacker to manipulate security policies or ingress rules, causing a breach in the system's overall security.

5. CVE-2025-1974:This flaw could enable attackers to bypass certain security mechanisms, putting the integrity of services behind the ingress-nginx-controller at risk.

Chainguard’s security team noticed the reports posted on March 25th, 2025 at 4:40pm EST and immediately initiated a review process. We assessed our own infrastructure to ensure that our internal systems remained secure, while simultaneously examining our product offerings to identify any affected images. Our robust security measures shielded our internal infrastructure from these specific vulnerabilities, and we quickly identified the Chainguard Containers that required patching. This situation presented a unique challenge for Chainguard — safeguarding our own operations while rapidly deploying fixes to protect customers of our container images — and after our fifth cup of coffee, we were wired and ready to take on the challenge.

Patching and Rebuilding Affected Image Versions 

Here at Chainguard, we built a new operating system distribution, Chainguard OS, that is designed specifically to deliver continuous, real-time updates so that our customers can benefit from the latest security updates and functionality that open source maintainers work so hard to build. And underpinning the Chainguard OS is our Chainguard Factory, which possesses automation and infrastructure that is among the fastest in the world at uniting source code, third party libraries, compilers, toolchains, and more into a software system for our customers to depend on in production. Those two powerful foundations together, enabled Chainguard to rebuild fully patched ingress-nginx-controller images within 17 hours of the CVE disclosures and protect our customers’ software supply chains.

Ingress-NGINX-controller Version 1.11 and 1.12: These two version streams are supported by the project maintainers. Upstream patches became available within a few hours and the Chainguard Factory pulled in upstream changes automatically and spun up new builds for both FIPS and non-FIPS variants. The upstream fixes were published around 7:40pm ET on March 24th and by 12:40pm ET on March 25th, Chainguard had published rebuilt container images that included upstream patches for the five CVEs listed above and distributed them to customers.

Ingress-NGINX-controller Version 1.10: This version is not supported by the upstream maintainers and thus did not receive a patch from upstream, despite being affected by the vulnerabilities; however, we knew that some of our customers were relying on this image version in sensitive production environments. To address the vulnerabilities in this version, the Chainguard engineering team reviewed upstream patches for versions 1.11 and 1.12, determined that changes required by the patches were minimal, and used our automation and tooling to backport the upstream fixes to version 1.10. Again, we accomplished all of this work in less than 17 hours – even before scanner databases were updated for the presence of this critical attack path.

Chainguard’s Commitment to Supporting Customers and Their Use Cases

As we emphasized above, Ingress-NGINX-controller version 1.10 is no longer supported by the upstream maintainers. And historically, Chainguard has only supported and rebuilt upstream maintained image versions; however, with our new Chainguard EOL Grace Period capability, we are now supporting older versions of software beyond their typical end-of-life date. Our ability to quickly analyze, path and deploy new versions for software versions that may not be fully supported by upstream allows us to provide more time and flexibility to our customers. And we continue to deliver on our industry leading SLA by leveraging our world-class automation and expertise of our team.

Interested in our best-in-class support for containers? Reach out today to learn more about how Chainguard Containers can help you stay safe from vulnerabilities like the ones highlighted above.