Описание
Traefik versions >= v3.7.0 and <= v3.7.10 contain an authentication bypass in the Kubernetes Ingress NGINX provider. The TLS option generated for an Ingress carrying the nginx.ingress.kubernetes.io/auth-tls-secret annotation was named after the Ingress namespace and name. As a result, two Ingress objects sharing the same host, the same client CA secret, and the same client-authentication mode produced two distinct TLS option names for that host. Traefik treats this as a TLS options conflict and falls back to the entry point's default TLS configuration, which does not request a client certificate, so a route configured with nginx.ingress.kubernetes.io/auth-tls-verify-client: "on" becomes reachable without a client certificate. Only the v3.7 line is affected; the issue is fixed in v3.7.11.
A flaw was found in Traefik. This vulnerability allows a remote attacker to bypass authentication, gaining unauthorized access to protected routes. This occurs due to a conflict in how Traefik handles Transport Layer Security (TLS) options when specific Kubernetes Ingress objects are configured. The conflict causes Traefik to use a less secure default configuration, negating the requirement for client certificates.
Отчет
A flaw was found in Traefik's Kubernetes Ingress NGINX provider (v3.7.0 through v3.7.10) where TLS options generated for Ingress objects using the auth-tls-secret annotation are incorrectly named using the namespace and Ingress name. When multiple Ingress objects share the same host, client CA secret, and authentication mode, Traefik misinterprets the resulting distinct TLS option names as a configuration conflict. This causes Traefik to regress to default entrypoint TLS options that do not request client certificates, allowing remote unauthenticated attackers to bypass mTLS requirements on routes protected by auth-tls-verify-client.
Меры по смягчению последствий
Consolidate Ingress rules sharing the same host and client CA secret into a single Ingress resource, or avoid using the auth-tls-secret annotation across multiple distinct Ingress objects for a shared host. Alternatively, enforce client certificate validation at an upstream load balancer or API gateway until patched.
Затронутые пакеты
| Платформа | Пакет | Состояние | Рекомендация | Релиз |
|---|---|---|---|---|
| Red Hat OpenShift Dev Spaces | devspaces/traefik-rhel9 | Not affected | ||
| Red Hat OpenShift GitOps | openshift-gitops-1/argo-rollouts-rhel8 | Not affected | ||
| Red Hat OpenShift GitOps | openshift-gitops-1/argo-rollouts-rhel9 | Not affected |
Показывать по
Дополнительная информация
Статус:
EPSS
7.5 High
CVSS3
Связанные уязвимости
Traefik versions >= v3.7.0 and <= v3.7.10 contain an authentication bypass in the Kubernetes Ingress NGINX provider. The TLS option generated for an Ingress carrying the nginx.ingress.kubernetes.io/auth-tls-secret annotation was named after the Ingress namespace and name. As a result, two Ingress objects sharing the same host, the same client CA secret, and the same client-authentication mode produced two distinct TLS option names for that host. Traefik treats this as a TLS options conflict and falls back to the entry point's default TLS configuration, which does not request a client certificate, so a route configured with nginx.ingress.kubernetes.io/auth-tls-verify-client: "on" becomes reachable without a client certificate. Only the v3.7 line is affected; the issue is fixed in v3.7.11.
Traefik versions >= v3.7.0 and <= v3.7.10 contain an authentication by ...
Traefik versions >= v3.7.0 and <= v3.7.10 contain an authentication bypass in the Kubernetes Ingress NGINX provider. The TLS option generated for an Ingress carrying the nginx.ingress.kubernetes.io/auth-tls-secret annotation was named after the Ingress namespace and name. As a result, two Ingress objects sharing the same host, the same client CA secret, and the same client-authentication mode produced two distinct TLS option names for that host. Traefik treats this as a TLS options conflict and falls back to the entry point's default TLS configuration, which does not request a client certificate, so a route configured with nginx.ingress.kubernetes.io/auth-tls-verify-client: "on" becomes reachable without a client certificate. Only the v3.7 line is affected; the issue is fixed in v3.7.11.
EPSS
7.5 High
CVSS3