Summary
CVE-2025-1974 is a critical remote code execution flaw in Kubernetes Ingress-NGINX, allowing unauthenticated attackers with pod network access to run arbitrary code by exploiting unsafe annotation handling. This can lead to the theft of Kubernetes Secrets and full cluster compromise. It affects versions below 1.11.5 and 1.12.1. Immediate patching and securing the admission webhook are strongly advised.
Urgent Actions Required
- Update Ingress-NGINX to version 1.11.5 or 1.12.1 immediately.
- Restrict external access to the admission controller webhook endpoint.
- Audit ingress objects for unsafe or untrusted annotations such as nginx.ingress.kubernetes.io/configuration-snippet.
- Apply runtime detection rules (e.g., Falco or Sysdig) to monitor for suspicious shared library loads from /proc.
- Check for signs of exploitation using available public PoCs (e.g., IngressNightmare, nginxnightmare).
Which Systems Are Vulnerable to CVE-2025-1974?
Technical Overview
- Vulnerability Type: Remote Code Execution (RCE) via Unsafe Annotation Handling in Admission Controller
- Affected Software/Versions:
- Ingress-NGINX < 1.11.5
- Ingress-NGINX < 1.12.1
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
How Does the CVE-2025-1974 Exploit Work?
The attack typically follows these steps:
What Causes CVE-2025-1974?
Vulnerability Root Cause:
This vulnerability comes from poor validation of ingress annotations in the Ingress-NGINX controller. Attackers can inject malicious configurations, leading to remote code execution. Since the controller often has high privileges, this can result in full cluster compromise without authentication.
How Can You Mitigate CVE-2025-1974?
If immediate patching is delayed or not possible:
- Limit access to the Ingress-NGINX admission controller to trusted internal services.
- Use network policies to isolate it from untrusted namespaces.
- Disable or audit risky annotations like configuration-snippet.
- Deploy a WAF to block suspicious ingress requests.
- Monitor controller pods for signs of RCE, such as loading from /proc/*/fd/*.
Which Assets and Systems Are at Risk?
Asset Types Affected:
- Kubernetes Clusters – Environments using vulnerable versions of Ingress-NGINX controller (< v1.11.5 and < v1.12.1)
- Ingress Controllers – Specifically those configured with the admission webhook enabled and exposed within the pod network
- Admission Control Workflows – Workloads relying on the ingress-nginx admission controller for ingress object validation
Business-Critical Systems at Risk:
- Production Clusters – If ingress controllers have elevated permissions or default access to all Kubernetes Secrets
- Service-to-Service Communication – Risk of lateral movement and secret theft from workloads using shared ingress resources
- Multi-tenant Kubernetes Environments – Higher risk due to broader attack surface and potential cross-namespace compromise
- DevOps & CI/CD Infrastructure – Often run with sensitive tokens that can be exposed if accessed via ingress routes
Exposure Level:
- Internal Cluster Networks – Vulnerable if the ingress admission controller is reachable by any compromised pod
- Publicly Exposed Ingress Controllers – Higher exploitation risk if admission webhooks are exposed externally
- Staging/Test Clusters – Frequently overlooked, yet often configured with similar access and fewer protections
Will Patching CVE-2025-1974 Cause Downtime?
Patch application impact: Low to Moderate. Update Ingress-NGINX to version 1.11.5 or 1.12.1 to fix the issue. Most clusters can patch with minimal downtime using tools like kubectl or Helm. For setups using advanced annotations, test in staging first.
Mitigation (if immediate patching is not possible): Limit access to the ingress-nginx webhook to trusted services, apply strict RBAC to reduce Secret access, and review or disable risky annotations (like Lua blocks). However, this does not fully stop the threat—unauthenticated access from inside the pod network is still dangerous. Public exploits exist, and real attacks have been seen. Only a full patch provides complete protection.
How Can You Detect CVE-2025-1974 Exploitation?
Exploitation Signatures:
- AdmissionReview requests containing ingress annotation values like ssl_engine or load_module, aiming to load shared libraries via malicious NGINX directives
- Annotation values referencing temporary shared object (.so) files uploaded via NGINX client-body buffering (e.g., /tmp/nginx/client-body/...).
Indicators of Compromise (IOCs/IOAs):
- AdmissionReview payloads with ingress annotations containing ssl_engine load_module lines.
- NGINX validation logs (nginx -t) showing errors like “could not load shared library” during configuration checks.
- .so files unexpectedly present in NGINX client-body temp directories (/tmp/nginx/...).
Behavioral Indicators:
- NGINX processes within the Ingress-NGINX pod using mmap or mmap2 to load shared libraries from file descriptors under /proc/*/fd/*.
- Error log entries indicating malicious directive injection during admission webhook invocation.
Alerting Strategy:
- Priority: Critical
- Trigger alerts for:
- AdmissionReview requests with annotations containing ssl_engine or load_module directives.
- Log events from nginx -t showing shared library loading failures.
- Runtime detection of shared libraries being loaded from /proc/*/fd/* within ingress-nginx pods.
Remediation & Response
Patch/Upgrade Instructions:
Mitigation Steps if No Patch:
- Restrict access to the ingress-nginx admission webhook, allowing only trusted internal services.
- Enforce strict RBAC policies to limit controller access to Secrets.
- Audit or disable risky annotations, such as ssl_engine, load_module, or custom Lua blocks.
- Use runtime detection (e.g., Falco/Sysdig) to monitor shared library loads from /proc/fd directories.
Remediation Timeline:
- Immediate (0–2 hrs): Restrict webhook access and disable risky annotations.
- Within 8 hrs: Apply patches to ingress-nginx controller(s) to v1.11.5 or v1.12.1.
- Within 24 hrs: Confirm no vulnerable versions remain in staging or production clusters.
Rollback Plan:
- If upgrade issues arise, revert to the last known stable version of ingress-nginx.
- Ensure webhook restrictions and annotation audits remain in place until patch succeeds.
- Record rollback actions (version, timestamp, engineer) in your change management system.
Incident Response Considerations:
- Immediately isolate affected ingress-nginx pods to prevent further unauthorized code execution.
- Collect forensic logs: audit AdmissionReview requests, controller logs (nginx -t), and runtime detection alerts.
- Investigate for signs of shared-library load attempts or unexpected .so file writes.
- Fortify logging and validation post-patch to detect config injection attempts and unauthorized annotation usage.
Compliance & Governance Notes
Standards Impacted:
- General Security Standards (implied): General security standards like NIST 800-53 SI-2 and ISO 27001 A.12.6.1 usually apply to vulnerabilities allowing remote code execution and unauthorized access, even though the references don’t mention specific standards.
Audit Trail Requirement:
- Monitor and log all AdmissionReview webhook requests to detect suspicious or malformed ingress objects attempting template injection or configuration tampering.
- Track loading of shared libraries in the ingress-nginx pod, especially via monitoring /proc/*/fd/* file descriptors for suspicious activity.
- Maintain runtime detection logs for rule-based alerts on loading of shared libraries from /proc in the NGINX ingress container (e.g., via Falco or Sysdig Secure).
- Record patching details: version upgrade dates, affected ingress-nginx controller instances, and applied remediation steps.
Policy Alignment:
- Ensure admission webhook endpoints of ingress-nginx are not publicly exposed to reduce remote exploitability.
- Enforce strict input validation and sanitization for Kubernetes Ingress objects annotations and uid fields to prevent template injection.
- Integrate continuous vulnerability scanning for ingress-nginx controller versions to promptly detect and remediate affected versions (prioritize upgrading to v1.11.5 or v1.12.1 and above).
- Include detection rules (e.g., Falco rules) for potential IngressNightmare exploitation in runtime security monitoring and incident response plans.
- Update incident response procedures to address detection → isolation → remediation steps upon suspected IngressNightmare exploitation.
Where Can I Find More Information on CVE-2025-1974?
CVSS Breakdown Table
| Metric | Value | Description |
|---|---|---|
| Base Score | 9.8 | Critical severity vulnerability allowing unauthenticated remote code execution and full cluster compromise |
| Attack Vector | Network | Exploitable remotely by sending malicious HTTP-based AdmissionReview requests to the ingress-nginx controller |
| Attack Complexity | Low | Exploitation requires no complex conditions—attack path is well-defined and technically straightforward |
| Privileges Required | None | No authentication or existing access is required to exploit the vulnerability (unauthenticated attackers can trigger the flaw) |
| User Interaction | None | No user interaction is needed to execute the exploit (e.g., no need for clicking or manual intervention) |
| Scope | Unchanged | The vulnerability affects the ingress-nginx controller itself; escalation to other components depends on the controller’s default privileges |
| Confidentiality Impact | High | Exploitation can lead to exfiltration of Kubernetes cluster secrets via access gained in the ingress-nginx pod |
| Integrity Impact | High | Allows injection and execution of arbitrary configuration or code within NGINX, leading to potential modification or tampering of system behavior |
