Ce mail provient de l'extérieur, restons vigilants ===================================================================== CERT-Renater Note d'Information No. 2026/VULN992 _____________________________________________________________________ DATE : 08/10/2026 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running Traefik (Go) versions prior to 2.11.58, 3.7.14. ==================================================================== https://github.com/traefik/traefik/security/advisories/GHSA-qm9f-w54v-q2qh https://github.com/traefik/traefik/security/advisories/GHSA-rv2h-qh7j-xrjw https://github.com/traefik/traefik/security/advisories/GHSA-53qr-784g-cj35 https://github.com/traefik/traefik/security/advisories/GHSA-qvj7-gq9c-hp7q https://github.com/traefik/traefik/security/advisories/GHSA-fh26-gfpp-7xxx https://github.com/traefik/traefik/security/advisories/GHSA-mwrr-6hp4-pxr6 _____________________________________________________________________ Preauthenticated Negotiate contaminates Traefik's globally shared backend connection pool High rtribotte published GHSA-qm9f-w54v-q2qh Oct 7, 2026 Package Traefik (Go) Affected versions >= v2.11.0, <= v2.11.57 >= v3.0.0, <= v3.7.13 Patched versions v2.11.58 v3.7.14 Description Summary There is a high severity authentication vulnerability in Traefik's handling of connection-bound backend authentication (NTLM and SPNEGO/Kerberos "Negotiate"). For each new frontend connection, Traefik sends the first backend request through a globally shared transport and only switches that connection to an isolated, per-frontend-connection transport after it observes an NTLM/Negotiate challenge in the backend's response. When a client preauthenticates — sending a valid Authorization: Negotiate token on its first request instead of following the standard challenge-first (401) handshake — the backend authenticates the shared-pool connection on that first request and returns a successful response. Because isolation is decided only after the response is seen, the now victim-authenticated backend socket remains in the shared pool, and it is neither drained nor closed. An unrelated, unauthenticated client on a completely separate frontend connection can then be assigned that socket and act with the victim's identity, performing victim-authorized reads or writes. Exploitation requires Traefik to proxy a connection-bound NTLM/Negotiate backend with connection reuse enabled, and a legitimate client that preauthenticates rather than following the standard challenge-first handshake. The ordinary challenge-first flow is not affected: it installs a dedicated backend transport before the credential-bearing request, so the authenticated socket never enters shared pool. This is a distinct issue from GHSA-qqjf-53cj-pwvv (which fixed a missing HTTP/3 transport holder): it occurs on ordinary HTTP/1.1 HTTP/2 frontend connections because the credential-bearing first request reaches the shared pool before any holder can isolate it. The behavior was introduced together with connection-bound NTLM/Kerberos support in v2.11.0 and v3.0.0. Traefik v3.0 through v3.6 are end-of-life and are also affected; they will not receive a fix on their own line, and users on those versions must upgrade to v3.7.14. Patches https://github.com/traefik/traefik/releases/tag/v2.11.58 https://github.com/traefik/traefik/releases/tag/v3.7.14 For more information If you have any questions or comments about this advisory, please open an issue. Severity High 7.0/ 10 CVSS v4 base metrics Exploitability Metrics Attack Vector Network Attack Complexity Low Attack Requirements Present Privileges Required None User interaction None Vulnerable System Impact Metrics Confidentiality None Integrity None Availability None Subsequent System Impact Metrics Confidentiality High Integrity High Availability None CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N CVE ID No known CVE Weaknesses Weakness CWE-287 Weakness CWE-863 Credits @lyhtheori lyhtheori Reporter _____________________________________________________________________ Ingress-NGINX provider: colliding auth-tls-secret names merge two client CAs into one TLS option, so a host is gated by another host's CA High rtribotte published GHSA-rv2h-qh7j-xrjw Oct 7, 2026 Package Traefik (Go) Affected versions >= v3.7.0, <= v3.7.13 Patched versions v3.7.14 Description Summary There is a high severity vulnerability in Traefik's Kubernetes Ingress NGINX provider. The TLS option generated for an Ingress carrying the nginx.ingress.kubernetes.io/auth-tls-secret annotation is named from the referenced Secret's namespace and name after normalizing them, which replaces every dot with a dash. Two Secrets whose names differ only by a dot and a dash, such as my.secret and my-secret, therefore produce the same TLS option name, and the Ingress processed second silently reuses the option built for the first one. A host configured to require client certificates issued by its own CA is then gated by another host's CA: certificates from that other CA are accepted, while the host's legitimate clients are refused. In Traefik v3.7.0 to v3.7.10, where the generated name also included the Ingress name, the same collision could occur between Ingresses whose names normalize identically. The provider now keeps the resource names as is in the names it generates. Traefik v2 and Traefik v3 versions before v3.7.0 are not affected: the auth-tls-secret annotation is supported by the Ingress NGINX provider since v3.7.0. Patches https://github.com/traefik/traefik/releases/tag/v3.7.14 For more information If you have any questions or comments about this advisory, please open an issue. Severity High 7.0/ 10 CVSS v4 base metrics Exploitability Metrics Attack Vector Network Attack Complexity Low Attack Requirements Present Privileges Required None User interaction None Vulnerable System Impact Metrics Confidentiality None Integrity None Availability None Subsequent System Impact Metrics Confidentiality High Integrity High Availability None CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N CVE ID No known CVE Weaknesses Weakness CWE-287 Credits @scofaild23 scofaild23 Reporter _____________________________________________________________________ FastProxy backend connection pool leaks connection-bound NTLM/Negotiate identity to unauthenticated clients High rtribotte published GHSA-53qr-784g-cj35 Oct 7, 2026 Package Traefik (Go) Affected versions >= v3.2.0, <= v3.7.13 Patched versions v3.7.14 Description Summary There is a high severity vulnerability in Traefik's experimental FastProxy implementation. Traefik isolates connection-bound NTLM and Negotiate (Kerberos) backend authentication by pinning the backend connection on which a client authenticated to that client's frontend connection, so that no other client is ever served on it. When experimental.fastProxy is enabled, requests to plain http:// backends are dispatched through FastProxy's own connection pool, which was keyed only by ServersTransport and target URL and did not apply that isolation. Against a backend that binds an identity to a persistent connection, an unauthenticated client on a brand-new frontend connection could be handed a backend connection on which a victim had already completed an NTLM or Negotiate handshake, and be served as that victim, reading victim-only data and performing actions in the victim's name without presenting any credentials. Affected deployments require experimental.fastProxy enabled, a plain HTTP backend using connection-bound NTLM or Negotiate authentication, and backend keep-alive; the default proxy implementation is not affected. FastProxy now dispatches requests carrying an NTLM or Negotiate credential through a connection pool dedicated to their frontend connection, and every subsequent request on that frontend connection to the same backend reuses it. FastProxy was introduced in Traefik v3.2: v3.2 through v3.6 are affected but are no longer maintained and will not receive a patch of their own, users on those lines must upgrade to v3.7.14. Traefik v2 and earlier v3 versions are not affected. Patches https://github.com/traefik/traefik/releases/tag/v3.7.14 For more information If you have any questions or comments about this advisory, please open an issue. Severity High 7.0/ 10 CVSS v4 base metrics Exploitability Metrics Attack Vector Network Attack Complexity Low Attack Requirements Present Privileges Required None User interaction None Vulnerable System Impact Metrics Confidentiality None Integrity None Availability None Subsequent System Impact Metrics Confidentiality High Integrity High Availability None CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N CVE ID No known CVE Weaknesses Weakness CWE-488 Credits @AndyAnh174 AndyAnh174 _____________________________________________________________________ Kubernetes Ingress NGINX provider: ssl-passthrough sibling HTTP router serves the auth-protected backend without auth High rtribotte published GHSA-qvj7-gq9c-hp7q Oct 7, 2026 Package Traefik (Go) Affected versions >= v3.7.13, <= v3.7.13 Patched versions v3.7.14 Summary There is a high severity vulnerability in Traefik's Kubernetes Ingress NGINX provider. Since v3.7.13, an Ingress carrying the nginx.ingress.kubernetes.io/ssl-passthrough: "true" annotation gets, besides its TCP passthrough router, an HTTP router on the non-TLS entry points that proxies to the backend. That router was built outside the regular per-rule processing, so the access-control annotations set on the same Ingress, such as auth-type with auth-secret, auth-url and whitelist-source-range, were parsed but never turned into middlewares on it. An unauthenticated client reaching the HTTP entry point with the Ingress host could therefore reach a backend the operator had annotated as protected, with no authentication and no source allow-listing applied, and nothing logged. The HTTP side of an ssl-passthrough Ingress is now built like any other Ingress, with its annotation directives applied; the routers it generates are renamed as a result, see the v3.7.14 migration guide. Traefik v2 and Traefik v3 versions before v3.7.13 are not affected. Patches https://github.com/traefik/traefik/releases/tag/v3.7.14 For more information If you have any questions or comments about this advisory, please open an issue. Severity High 7.0/ 10 CVSS v4 base metrics Exploitability Metrics Attack Vector Network Attack Complexity Low Attack Requirements Present Privileges Required None User interaction None Vulnerable System Impact Metrics Confidentiality None Integrity None Availability None Subsequent System Impact Metrics Confidentiality High Integrity High Availability None CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N CVE ID No known CVE Weaknesses Weakness CWE-306 _____________________________________________________________________ snicheck skips the check when `req.TLS` is nil (HTTP/2 `:scheme http`) High rtribotte published GHSA-fh26-gfpp-7xxx Oct 7, 2026 Package Traefik (Go) Affected versions <= v2.11.57 >= v3.0.0, <= v3.7.13 Patched versions v2.11.58 v3.7.14 Description Summary There is a high severity vulnerability in Traefik's SNI check, which makes sure a request received on a TLS connection is only served by an HTTP router whose TLS options match the ones negotiated for that connection. The check was skipped entirely when the request carried no TLS connection state. Traefik built with Go 1.27 leaves that state unset for HTTP/2 requests sent with the :scheme http pseudo-header over a TLS connection, so an unauthenticated client could have such a request served by a router with different TLS options, for example one requiring a client certificate, without presenting one. Official Traefik binaries and images are built with Go 1.26 and are not exposed, but any Traefik build made with Go 1.27, including third-party rebuilds, is; Traefik now always sets the TLS state of requests received on a TLS connection, so the check applies whatever the toolchain. Traefik v3 versions below v3.7 are affected but are no longer maintained and will not receive a patch of their own; the remedy for those users is to upgrade to a maintained, patched version. Patches https://github.com/traefik/traefik/releases/tag/v2.11.58 https://github.com/traefik/traefik/releases/tag/v3.7.14 For more information If you have any questions or comments about this advisory, please open an issue. Severity High 7.0/ 10 CVSS v4 base metrics Exploitability Metrics Attack Vector Network Attack Complexity Low Attack Requirements Present Privileges Required None User interaction None Vulnerable System Impact Metrics Confidentiality None Integrity None Availability None Subsequent System Impact Metrics Confidentiality High Integrity High Availability None CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N CVE ID No known CVE Weaknesses No CWEs _____________________________________________________________________ Ingress-NGINX provider forwards forged Ssl-Client-* identity headers on its HTTP route High rtribotte published GHSA-mwrr-6hp4-pxr6 Oct 7, 2026 Package Traefik (Go) Affected versions >= v3.7.0, <= v3.7.13 Patched versions v3.7.14 Description Summary There is a high severity vulnerability in Traefik's Kubernetes Ingress-NGINX provider. For an Ingress carrying the nginx.ingress.kubernetes.io/auth-tls-pass-certificate-to-upstream annotation, the middleware that owns the Ssl-Client-* request headers is attached only to the TLS router, so the plaintext HTTP router generated for the same Ingress forwards those headers exactly as the client sent them. That router normally only issues a redirect, but when nginx.ingress.kubernetes.io/ssl-redirect: "false" is set it reaches the backend, and an unauthenticated client can then supply Ssl-Client-Verify: SUCCESS together with a chosen certificate subject and issuer. A backend that trusts those proxy-generated fields as a mTLS identity authorizes the request even though no client certificate was presented. Only the Traefik v3.7 line is affected: support for the auth-tls-pass-certificate-to-upstream annotation was added in v3.7.0, and earlier versions do not translate it. Patches https://github.com/traefik/traefik/releases/tag/v3.7.14 For more information If you have any questions or comments about this advisory, please open an issue. Severity High 7.0/ 10 CVSS v4 base metrics Exploitability Metrics Attack Vector Network Attack Complexity Low Attack Requirements Present Privileges Required None User interaction None Vulnerable System Impact Metrics Confidentiality None Integrity None Availability None Subsequent System Impact Metrics Confidentiality High Integrity High Availability None CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N CVE ID No known CVE Weaknesses No CWEs Credits @Kushalkhemka Kushalkhemka Finder @mayank-jangid-moon mayank-jangid-moon Finder @skigeek16 skigeek16 Finder @opensec-intelligence opensec-intelligence Tool ========================================================= + CERT-RENATER | tel : 01-53-94-20-44 + + 23/25 Rue Daviel | fax : 01-53-94-20-41 + + 75013 Paris | email:cert@support.renater.fr + =========================================================