CVE-2025-66491: Traefik has Inverted TLS Verification Logic in its ingress-nginx Provider
Impact
There is a potential vulnerability in Traefik NGINX provider managing the nginx.ingress.kubernetes.io/proxy-ssl-verify annotation.
The provider inverts the semantics of the nginx.ingress.kubernetes.io/proxy-ssl-verify annotation. Setting the annotation to "on" (intending to enable backend TLS certificate verification) actually disables verification, allowing man-in-the-middle attacks against HTTPS backends when operators believe they are protected.
Patches
- https://github.com/traefik/traefik/releases/tag/v3.6.3
For more information
If you have any questions or comments about this advisory, please open an issue.
<details> <summary>Original Description</summary>
Summary
A logic error in Traefik's experimental ingress-nginx provider inverts the semantics of the nginx.ingress.kubernetes.io/proxy-ssl-verify annotation. Setting the annotation to "on" (intending to enable backend TLS certificate verification) actually disables verification, allowing man-in-the-middle attacks against HTTPS backends when operators believe they are protected.
Details
In pkg/provider/kubernetes/ingress-nginx/kubernetes.go at line 512, the InsecureSkipVerify field is set using inverted logic:
go nst := &namedServersTransport{ Name: provider.Normalize(namespace + "-" + name), ServersTransport: &dynamic.ServersTransport{ ServerName: ptr.Deref(cfg.ProxySSLName, ptr.Deref(cfg.ProxySSLServerName, "")), InsecureSkipVerify: strings.ToLower(ptr.Deref(cfg.ProxySSLVerify, "off")) == "on", }, }
The expression == "on" evaluates to true when the annotation is "on", setting InsecureSkipVerify: true. In Go's crypto/tls, InsecureSkipVerify: true means "do not verify the server's certificate" — the opposite of what proxy-ssl-verify: "on" should do according to NGINX semantics.
Current behavior: | Annotation Value | InsecureSkipVerify | Actual Result | |------------------|-------------------|---------------| | "on" | true | Verification disabled ❌ | | "off" (default) | false | Verification enabled |
Expected behavior (per NGINX semantics): | Annotation Value | InsecureSkipVerify | Expected Result | |------------------|-------------------|-----------------| | "on" | false | Verification enabled | | "off" (default) | true | Verification disabled |
The test in pkg/provider/kubernetes/ingress-nginx/kubernetestest.go lines 397-403 confirms this inverted behavior is codified as "expected":
go ServersTransports: map[string]dynamic.ServersTransport{ "default-ingress-with-proxy-ssl": { ServerName: "whoami.localhost", InsecureSkipVerify: true, // Wrong: should be false when annotation is "on" RootCAs: []types.FileOrContent{"-----BEGIN CERTIFICATE-----"}, }, },
Affected versions: v3.5.0 through current master (introduced in commit 9bd5c617820f2a8d23b50b68d114bb7bc464eccd)
Pavel Kohout Aisle Research </details>
-
Other sources
Traefik is an HTTP reverse proxy and load balancer. Versions 3.5.0 through 3.6.2 have inverted TLS verification logic in the nginx.ingress.kubernetes.io/proxy-ssl-verify annotation. Setting the annotation to "on" (intending to enable backend TLS certificate verification) actually disables verification, allowing man-in-the-middle attacks against HTTPS backends when operators believe they are protected. This issue is fixed in version 3.6.3.
— MITRE
Affected Software
Remediation
Event History
Frequently Asked Questions
What is the severity of CVE-2025-66491?
The severity of CVE-2025-66491 is currently classified as high due to the potential for misconfiguration within the Traefik NGINX provider.
How do I fix CVE-2025-66491?
To fix CVE-2025-66491, update the Traefik version to 3.6.3 or later, ensuring proper handling of the proxy-ssl-verify annotation.
Which versions of Traefik are affected by CVE-2025-66491?
CVE-2025-66491 affects Traefik versions from 3.5.0 to 3.6.2.
What is the root cause of CVE-2025-66491?
The root cause of CVE-2025-66491 is the inversion of semantics in the proxy-ssl-verify annotation within the Traefik NGINX provider.
Are there any workarounds for CVE-2025-66491?
Currently, the recommended approach is to update to the secure version, as no effective workarounds are provided for CVE-2025-66491.