CVE-2025-66491: 
NixOS vulnerability analysis and mitigation

CVE-2025-66491 is a logic inversion vulnerability in Traefik's experimental Kubernetes ingress-nginx provider that causes TLS certificate verification to be disabled when operators explicitly configure it to be enabled. Discovered and reported by Pavel Kohout of Aisle Research, it was disclosed on December 8, 2025. Affected versions are Traefik v3.5.0 through v3.6.2; v3.6.3 contains the fix. It carries a CVSS v3.1 base score of 5.9 (Medium) (Github Advisory, Traefik Advisory).

The root cause is a boolean logic error (CWE-295: Improper Certificate Validation) in pkg/provider/kubernetes/ingress-nginx/kubernetes.go at line 512. The InsecureSkipVerify field of Go's crypto/tls is set using the expression strings.ToLower(ptr.Deref(cfg.ProxySSLVerify, "off")) == "on", which evaluates to true when the annotation is "on" — but InsecureSkipVerify: true in Go means certificate verification is skipped, the exact opposite of the intended NGINX semantics. The fix (commit 14a1aed) changes the comparison to == "off", so that InsecureSkipVerify is true only when verification is explicitly disabled, and false (verification enforced) when the annotation is "on". Notably, the inverted behavior was also codified in the test suite as "expected," meaning it went undetected during testing (Traefik Advisory, Fix Commit).

Attackers positioned on the network path between Traefik and HTTPS backend services can perform man-in-the-middle (MITM) attacks, intercepting, decrypting, and potentially manipulating traffic. The confidentiality impact is rated High, as sensitive data transmitted between Traefik and backend systems — including credentials, API responses, and internal service data — can be exposed to an unauthorized party. Integrity and availability are not directly impacted by this vulnerability. The deceptive nature of the bug is particularly dangerous: operators who believe they have hardened their environment by enabling TLS verification are in fact running with verification disabled (Github Advisory, Traefik Advisory).

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 vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.006–0.012%, placing it in the low percentile for near-term exploitation likelihood. Exploitation requires an attacker to be positioned on the network path between Traefik and a backend (high attack complexity), limiting opportunistic exploitation (Github Advisory).

1. Identify target environment: Determine that the target Kubernetes cluster uses Traefik v3.5.0–v3.6.2 as its ingress controller with the experimental ingress-nginx provider enabled, and that one or more ingresses have the nginx.ingress.kubernetes.io/proxy-ssl-verify: "on" annotation set.
2. Gain network position: Position on the network path between Traefik and the HTTPS backend service — for example, via ARP spoofing, BGP hijacking, or compromise of an intermediate network node within the cluster or data center network.
3. Present a rogue TLS certificate: Stand up a TLS listener presenting a self-signed or attacker-controlled certificate for the backend service's hostname. Because InsecureSkipVerify is incorrectly set to true, Traefik will accept any certificate without validation.
4. Intercept and relay traffic: Decrypt and inspect (or modify) the plaintext traffic from Traefik before re-encrypting and forwarding it to the legitimate backend, completing the MITM channel and exfiltrating sensitive data (Traefik Advisory).

• Network: Unexpected TLS handshakes from Traefik to backend services using certificates not issued by the expected CA; unusual intermediate hosts appearing in network flows between Traefik pods and backend service IPs.
• Logs: Absence of TLS certificate validation errors in Traefik logs despite backends presenting untrusted or self-signed certificates (which would normally be logged); anomalous latency spikes on backend connections that could indicate traffic interception.
• Configuration Audit: Presence of nginx.ingress.kubernetes.io/proxy-ssl-verify: "on" annotations on ingress resources in clusters running Traefik v3.5.0–v3.6.2 — these should be treated as effectively having verification disabled until patched.

Upgrade Traefik to version v3.6.3 or later, which corrects the boolean logic inversion in the ingress-nginx provider (Traefik Release). For environments that cannot be immediately patched, audit all ingresses using the nginx.ingress.kubernetes.io/proxy-ssl-verify annotation and treat any set to "on" as having verification disabled until the upgrade is applied. As interim compensating controls, consider implementing network segmentation to restrict lateral movement between Traefik and backends, deploying mutual TLS (mTLS) at the application layer, or using certificate pinning for critical backend connections (Github Advisory).

The Traefik community forum published a security update announcement covering this and related fixes (Traefik Community). The vulnerability received coverage from eSecurity Planet and was discussed in the Risky Business security newsletter and podcast. Security researcher Catalin Cimpanu (@campuscodi) noted the issue on Mastodon, and a technical blog post from Aisle Research (the discovering organization) titled "CVE-2025-66491: Traefik's verify=on Turned TLS Off" provided additional community context. The Hacker News community also discussed the vulnerability, highlighting the irony of a security annotation producing the opposite of its intended effect.