CVE-2026-25518 Overview
CVE-2026-25518 is a Denial of Service (DoS) vulnerability affecting cert-manager, a widely-used Kubernetes add-on that manages certificates and certificate issuers. The vulnerability exists in the cert-manager-controller component which performs DNS lookups during ACME DNS-01 challenge processing. By default, these lookups utilize standard unencrypted DNS, allowing attackers who can intercept and modify DNS traffic to inject crafted entries into cert-manager's DNS cache. Accessing these malicious cache entries triggers a panic in the controller, causing service disruption.
Critical Impact
Attackers who can intercept DNS traffic or control the authoritative DNS server for a domain being validated can cause complete denial of service of the cert-manager controller, disrupting certificate issuance and renewal across Kubernetes clusters.
Affected Products
- cert-manager versions 1.18.0 to before 1.18.5
- cert-manager versions 1.19.0 to before 1.19.3
Discovery Timeline
- 2026-02-04 - CVE-2026-25518 published to NVD
- 2026-02-05 - Last updated in NVD database
Technical Details for CVE-2026-25518
Vulnerability Analysis
This vulnerability stems from improper input validation (CWE-129: Improper Validation of Array Index) in the DNS response handling logic of cert-manager's controller. When performing ACME DNS-01 challenges, the cert-manager-controller conducts DNS lookups for zone discovery and propagation self-checks. These operations are performed over unencrypted DNS by default, creating an attack surface for man-in-the-middle attacks.
An attacker positioned to intercept network traffic between the cert-manager-controller pod and DNS servers can inject malformed DNS responses. When cert-manager processes these crafted responses and stores them in its DNS cache, subsequent access to these poisoned cache entries causes the application to panic due to improper array index validation.
The vulnerability requires network positioning that allows DNS traffic interception, which may be achievable through ARP spoofing, BGP hijacking, compromised network infrastructure, or by controlling a malicious authoritative DNS server for domains being validated.
Root Cause
The root cause is improper validation of array indices when processing DNS responses within the cert-manager-controller. The application fails to properly validate boundaries before accessing array elements from DNS response data, leading to a panic condition when encountering specially crafted malicious entries. Combined with the use of unencrypted DNS for ACME challenge processing, this creates an exploitable attack path.
Attack Vector
The attack requires network-level access to intercept and modify DNS traffic from the cert-manager-controller pod. This can be achieved through several scenarios:
Network Position Attack: An attacker with man-in-the-middle capabilities on the network path between cert-manager and DNS servers can inject crafted DNS responses.
Malicious DNS Server: If the authoritative DNS server for a domain undergoing ACME DNS-01 validation is controlled by an attacker, they can serve malicious responses directly.
Compromised Network Infrastructure: Attackers who have compromised routers, switches, or DNS resolvers in the communication path can manipulate DNS traffic.
The attack flow involves intercepting legitimate DNS queries from cert-manager, crafting a malicious response that exploits the array index validation flaw, and delivering this response to be cached. When cert-manager subsequently accesses the poisoned cache entry, the controller panics and becomes unavailable.
Detection Methods for CVE-2026-25518
Indicators of Compromise
- Unexpected cert-manager-controller pod restarts or crash loops in Kubernetes
- Panic errors in cert-manager-controller logs related to DNS or cache operations
- Certificate issuance or renewal failures across the cluster
- Anomalous DNS query/response patterns targeting the cert-manager-controller pod
Detection Strategies
- Monitor cert-manager-controller pod health and restart counts using Kubernetes monitoring tools
- Implement network monitoring to detect DNS traffic anomalies or suspicious DNS responses
- Configure alerting on cert-manager log entries containing panic messages
- Deploy DNS traffic analysis tools to identify potential cache poisoning attempts
Monitoring Recommendations
- Enable verbose logging on cert-manager-controller to capture detailed DNS operation logs
- Implement Kubernetes pod disruption budget monitoring for cert-manager deployments
- Set up certificate expiration alerts to detect renewal failures that may indicate exploitation
- Monitor network flows to/from cert-manager pods for unusual DNS traffic patterns
How to Mitigate CVE-2026-25518
Immediate Actions Required
- Upgrade cert-manager to version 1.18.5 or 1.19.3 immediately
- Review cert-manager-controller logs for evidence of exploitation attempts
- Consider implementing DNS-over-TLS or DNS-over-HTTPS for cert-manager DNS queries
- Restrict network access to/from cert-manager-controller pods using Kubernetes NetworkPolicies
Patch Information
The cert-manager project has released patched versions that address this vulnerability:
- Version 1.18.5 for users on the 1.18.x branch
- Version 1.19.3 for users on the 1.19.x branch
The fixes are available in the following commits:
For complete details, refer to the GitHub Security Advisory GHSA-gx3x-vq4p-mhhv.
Workarounds
- Deploy Kubernetes NetworkPolicies to restrict DNS traffic from cert-manager pods to trusted DNS servers only
- Configure cert-manager to use encrypted DNS protocols where supported
- Implement network segmentation to limit attacker access to DNS traffic paths
- Consider using a local DNS resolver with DNSSEC validation as an intermediary
# Example NetworkPolicy to restrict cert-manager egress DNS traffic
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: cert-manager-dns-restriction
namespace: cert-manager
spec:
podSelector:
matchLabels:
app.kubernetes.io/name: cert-manager
policyTypes:
- Egress
egress:
- to:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: kube-system
- podSelector:
matchLabels:
k8s-app: kube-dns
ports:
- protocol: UDP
port: 53
- protocol: TCP
port: 53
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
