CVE-2026-25518: 
Wolfi vulnerability analysis and mitigation

CVE-2026-25518 is a Denial-of-Service (DoS) vulnerability in cert-manager's controller that can be triggered via a specially crafted DNS response during ACME DNS-01 challenge processing. The vulnerability was introduced in cert-manager v1.18.0 and affects versions 1.18.0 through 1.18.4 and 1.19.0 through 1.19.2; versions prior to 1.18.0 are unaffected. It was reported by Oleh Konko (@1seal), disclosed on February 2, 2026, and patched on the same day. It carries a CVSS v3.1 base score of 5.9 (Medium) (GitHub Advisory, Red Hat Bugzilla).

The root cause lies in the FindZoneByFqdn function within pkg/issuer/acme/dns/util/wait.go, which assumed the first element of a cached DNS response's Answer array was always a SOA record and performed an unchecked type assertion (Answer[0].(*dns.SOA)). This constitutes improper validation of array index (CWE-129) and incorrect type conversion (CWE-704). When a crafted DNS response places a non-SOA record (e.g., an NS record) at Answer[0] with the SOA record at a later position, the type assertion panics on the second call to FindZoneByFqdn when the response is retrieved from cache. An attacker can trigger this by intercepting unencrypted DNS traffic from the cert-manager-controller pod (a network-based man-in-the-middle attack) or by controlling the authoritative DNS server for the domain being validated (GitHub Advisory, Patch Commit).

Successful exploitation causes a panic in the cert-manager-controller process, resulting in a denial-of-service condition that disables all certificate management functionality in the affected Kubernetes cluster. This prevents certificate validation, renewal, and issuance operations from completing, which can lead to expired TLS certificates across services relying on cert-manager. There is no confidentiality or integrity impact — the vulnerability is limited to availability (GitHub Advisory, Red Hat Bugzilla).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at this time. The EPSS score is approximately 0.041% (6th percentile), indicating a low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires either network-level access to intercept DNS traffic from the cert-manager-controller pod (high attack complexity) or control of the authoritative DNS server for the validated domain (GitHub Advisory, Feedly).

1. Identify target: Confirm the target Kubernetes cluster is running cert-manager versions 1.18.0–1.18.4 or 1.19.0–1.19.2 and is using ACME DNS-01 challenge validation.
2. Position for DNS interception: Gain a network-level position capable of intercepting and modifying unencrypted UDP/TCP DNS traffic from the cert-manager-controller pod (e.g., via ARP spoofing, rogue DNS server on the same network segment, or BGP hijacking), OR control the authoritative DNS server for the domain being validated.
3. Craft malicious DNS response: Construct a DNS response where the Answer section contains a non-SOA record (e.g., an NS record) at index 0, followed by a SOA record at a later position. This response is valid per DNS standards but violates cert-manager's assumption.
4. Poison the DNS cache: Serve the crafted response to the cert-manager-controller during its first FindZoneByFqdn call, causing the malicious entry to be stored in cert-manager's internal DNS cache.
5. Trigger the panic: Wait for or trigger a second ACME DNS-01 validation for the same domain. When cert-manager retrieves the cached entry and attempts the unchecked type assertion Answer[0].(*dns.SOA), a Go runtime panic occurs, crashing the cert-manager-controller process and causing a DoS condition (GitHub Advisory, Patch Commit).

• Logs: Unexpected Go runtime panic messages in cert-manager-controller logs containing interface conversion: dns.RR is *dns.NS, not *dns.SOA or similar type assertion failure strings; repeated controller restarts logged by Kubernetes.
• Process/Pod Behavior: cert-manager-controller pod entering CrashLoopBackOff state in Kubernetes; sudden termination of the cert-manager-controller process without a graceful shutdown.
• Network: Anomalous DNS responses to cert-manager-controller queries where the Answer section begins with a non-SOA record type (NS, A, AAAA, etc.) for domains undergoing ACME DNS-01 validation; DNS traffic from the cert-manager pod being redirected to unexpected nameserver IPs.
• Kubernetes Events: Kubernetes events showing repeated pod restarts for the cert-manager-controller deployment; certificate issuance failures or timeouts across multiple Certificate resources in the cluster.

Upgrade cert-manager to version 1.18.5 (for the 1.18 branch) or 1.19.3 (for the 1.19 branch), which fix the panic by iterating over all DNS answer records to find the SOA entry rather than assuming it is at index 0. As a workaround, configure cert-manager to use DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT) to encrypt DNS queries, which reduces the risk of traffic interception (note: this does not mitigate the risk from a malicious authoritative DNS server). Additionally, implement network segmentation to restrict DNS traffic from the cert-manager-controller pod to trusted DNS resolvers only (GitHub Advisory, Patch Commit).

The vulnerability was credited to security researcher Oleh Konko (@1seal), who reported the issue, provided a detailed proof-of-concept, and contributed an initial patch. Red Hat tracked the issue via Bugzilla (Bug 2436941) with medium severity. IBM issued an advisory noting the impact on IBM watsonx Orchestrate with watsonx Assistant Cartridge. Community reaction has been muted given the moderate severity and limited exploitation complexity requirements (GitHub Advisory, Red Hat Bugzilla, IBM Advisory).