Several patches have been released to to address critical vulnerabilities that, if exploited, would enable attackers to gain access to all your Kubernetes clusters’ secrets.
Of note, these vulnerabilities are centered on the ingress-nginx controller, a popular method for exposing applications within Kubernetes to the Internet. If you are using ingress-nginx, these vulnerabilities pose a significant risk and it is crucial to take immediate action today to ensure the safety of your Kubernetes clusters.
How it plays out
The most serious zero-day vulnerability (CVE-2025-1974) lets an attacker from inside the Kubernetes cluster exploit the Validating Admission Controller feature to inject arbitrary configurations into ingress-nginx.
This means that an attacker can not only inject arbitrary code, but also access all secrets in all namespaces, allowing them to elevate privileges and move laterally within the cluster.
Admission controllers typically reside unrestricted within the network, without an authentication requirement, making them attractive targets for attackers.
This ability could allow secrets to be exposed with no administrative access required if using the default install configuration.
All secrets within all namespaces are vulnerable!
How can Secret Server help?
Secret Server can protect your application secrets and limit the blast radius of vulnerabilities of these types. Unfortunately, nginx only supports native Kubernetes secrets preventing Secret Server from providing a full mitigation for these specific vulnerabilities.
Many other secrets such as upstream service credentials don’t need to be stored in the Kubernetes cluster and can live in Secret Server instead.
Secrets ingress-nginx must access (Kubernetes Secrets only):
These secrets must be in the cluster because ingress-nginx directly references them via Ingress resource annotations or configuration:
| Use Case | Annotation / Config | Secret Type |
| TLS termination | tls.secretName | kubernetes.io/tls |
| Basic auth | nginx.ingress.kubernetes.io/auth-secret | Opaque |
| Client cert validation | nginx.ingress.kubernetes.io/auth-tls-secret | Opaque |
| External auth headers (JWT signing keys, etc) | Passed via annotations/secrets | Opaque |
These secrets must be Kubernetes-native because nginx is a pod running inside the cluster and doesn’t integrate directly with external vaults.
Secrets that can be stored in Secret Server instead:
These secrets are not used by ingress-nginx directly but are used by the backend service it routes to.:
| Use Case | Consumed By | Vaulting |
| DB credentials | Backend pods | Yes |
| API keys for upstream services | Backend pods | Yes |
| Encryption keys / signing keys | Apps or sidecars | Yes |
| Internal service tokens | Apps or service mesh | Yes |
| Admin credentials (rotated by ops) | Ops tools | Yes |
Recommendations
1. Patch
Even if you do not have your Kubernetes clusters accessible to the Internet, it is still critical to patch the environment to ensure proper isolation controls within Kubernetes are in place from an insider threat perspective.
2. Rotate your secrets
It is highly recommended that you rotate all secrets out of an abundance of caution in case something goes unnoticed or an attack vector of the vulnerability is missed.
3. Understand and document your inherent risks
Keep in mind that the secrets that must be stored in Kubernetes for nginx (see table above on what can or can’t be moved) are still exposed and, as suggested, should be addressed and rotated.
4. Review configuration risks
Additionally, examine your ingress-nginx configurations to make sure proxy headers or paths that can result in revealing important internal data are properly secured.
5. Move the locations of secrets when applicable
Move any secrets you can out of annotations/configs and into Secret Server. Configure apps to retrieve secrets at runtime via sidecar or external secret manager SDK.
6. Harden regardless
Harden ingress-nginx to restrict who can apply Ingress resources, such as disabling the vulnerable webhook if not patched, and use mTLS between services.
7. Always take the least privilege approach
Make sure access to Kubernetes resources follow a least privilege approach leveraging JIT privilege elevation if possible, and closely monitor your CPSM/CIEM recommendations and address them as needed.