CVE-2025-66491Medium· 5.9▾ SunlitTraefik Inverted TLS Verification Logic in ingress-nginx Provider
▾ Sunlit zone — Low / medium · no exploitation signal
impact 32.5 · likelihood 0 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Exploit-prediction probability, daily snapshots since Sep 12.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via OSV
Last analysed / modified upstream
0.2%
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.
If you have any questions or comments about this advisory, please open an issue.
<details> <summary>Original Description</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.
In pkg/provider/kubernetes/ingress-nginx/kubernetes.go at line 512, the InsecureSkipVerify field is set using inverted logic:
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/kubernetes_test.go lines 397-403 confirms this inverted behavior is codified as "expected":
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>github.com/traefik/traefik/v3 >= 3.5.0, < 3.6.3Upgrade to a patched release:
github.com/traefik/traefik/v3 3.6.3Connected by shared product, vendor, weakness, or advisory.
CVE-2026-32695MediumTraefik has Knative Ingress Rule Injection that Allows Host Restriction Bypass
GHSA-3wqc-mwfx-672pHigh· 7.5Traefik affected by Go oauth2/jws Improper Validation of Syntactic Correctness of Input vulnerability
GHSA-rvj4-q8q5-8grfMedium· 5.5ACME DNS: Azure Identity Libraries Elevation of Privilege Vulnerability
GHSA-7jmw-8259-q9jxMediumTraefik has unexpected behavior with IPv4-mapped IPv6 addresses
CVE-2026-40912High· 8.2Traefik has an StripPrefixRegex Middleware Authorization Bypass via Path/RawPath Desync
CVE-2026-54761High· 7.1Traefik: Kubernetes Gateway crossProviderNamespaces bypass allows HTTPRoute outside the allowlist to expose internal Traefik services