How we Secured our AWS EKS Cluster Against Critical Vulnerabilities

When our DevOps team received an AWS Security Notification about critical vulnerabilities in the ingress-nginx controller on March 24th, we initiated our AWS incident response plan immediately. Dubbed "IngressNightmare," these vulnerabilities could potentially allow attackers to execute arbitrary code and compromise our entire Amazon EKS cluster security posture.

Here’s how we found, assessed, and fixed this critical AWS security issue in 48 hours with zero service disruption and full AWS audit compliance.
‍

The threat: five critical vulnerabilities in AWS EKS

The most severe vulnerability, CVE-2025-1974 (CVSS 9.8), affected the ingress-nginx Validating Admission Controller in our AWS EKS environment. If exploited, it would allow attackers with pod network access to:
‍

• Inject malicious NGINX configurations
• Execute arbitrary code on the controller
• Potentially compromise all AWS EKS cluster secrets
• Create a compliance violation in our AWS Security Hub findings

Four more flaws completed the "IngressNightmare" package: CVE-2025-1098, CVE-2025-1097, CVE-2025-24514, and CVE-2025-24513, with CVSS scores ranging from 4.8 to 8.8.

Our AWS-compliant four-step response process
‍

1. AWS security assessment and intelligence gathering

We confirmed our exposure by checking our ingress-nginx version in our AWS EKS cluster. We were running version 1.11.3 – vulnerable to all five CVEs and flagged in our AWS Security Hub.

By reviewing trusted sources like AWS Security Bulletins, Wiz.io, Devoriales, and the Kubernetes Blog, we learned these issues affected 43% of cloud environments. The official patches were available in versions 1.11.5 and 1.12.1.
‍

2. AWS-compliant remediation planning

Following AWS Well-Architected Framework security best practices, we chose to upgrade to version 1.12.1. This version fixes all known vulnerabilities by:

• Disabling unsafe NGINX configuration validation
• Patching the injection vulnerabilities in the admission controller
• Creating detailed AWS CloudTrail logs for audit purposes
  ‍

3. Execution with zero downtime on AWS EKS

We used AWS EKS’s rolling update strategy to avoid downtime during the upgrade.
‍

4. AWS security verification and re-enabling security features

After confirming the upgrade succeeded, we turned the admission webhook back on and ran vulnerability scans against our public endpoints. No alerts were detected, confirming successful remediation. We updated our AWS Security Hub findings to mark the vulnerability as resolved.

Key takeaways for AWS engineering leaders
‍

1. Leverage AWS Security Notifications — Our prompt response was possible because we had properly configured AWS Security Hub alerts and SNS notifications.
2. Follow AWS Well-Architected Framework security best practices. A clear process aligned with AWS security standards helped us move from alerts to fixes in under 48 hours.
3. Use AWS EKS rolling updates for zero downtime — Kubernetes deployment updates on AWS EKS help secure infrastructure without service interruption.
4. Maintain AWS audit compliance — We logged all steps in AWS CloudTrail and wrote clear remediation notes for our next AWS security audit.

This incident showed that with the right process and AWS security tools, you can respond fast, reduce risk, and stay compliant.

Has your team faced similar challenges with AWS EKS security? We'd love to hear about your AWS security response processes in the comments.