ZeroHour

Vulnerabilities

13 CVEs · NVD, GitHub Advisories, CISA KEV, FIRST EPSS, GitHub PoC repos

CVEVulnerabilityCVSSEPSSFlagsAffectedExposurePublished
CVE-2026-88877
Authentication Bypass in Traefik Kubernetes ingress-nginx Provider

Traefik Proxy v3.7.0 through v3.7.11, when running the Kubernetes ingress-nginx provider, mishandles Ingresses that combine an authentication annotation (e.g. BasicAuth) with the nginx.ingress.kubernetes.io/from-to-www-redirect annotation, generating an extra 'sibling' router that matches on the host alone, carries only a RedirectRegex middleware, and points at the parent router's protected backend service. An attacker triggers the flaw by sending a request whose Host header carries a non-numeric or empty port (for example 'Host: www.example.com:x'), which the host matcher's canonicalization via net.SplitHostPort selects for the sibling router; the redirect pattern does not match, and because RedirectRegex is not a terminal handler the request is proxied straight to the backend with none of the Ingress's annotation-derived middlewares applied. The result is a complete bypass of authentication and of every other annotation-derived control on that route, including source-IP allowlisting, granting unauthenticated access to otherwise protected services. Only Traefik v3.7.0-v3.7.11 deployments using the Kubernetes ingress-nginx provider with Ingresses carrying both annotations are affected; Traefik v2 and v3 releases before v3.7.0 are not. The flaw is rated 9.3 (critical) under CVSS 4.0, is not in CISA's KEV, and there is no known public proof-of-concept or reported exploitation.

Do: Upgrade to Traefik v3.7.12 or later. Where an immediate upgrade is not possible, remove the nginx.ingress.kubernetes.io/from-to-www-redirect annotation from any Ingress that also carries an authentication annotation, or enforce access control at another layer (e.g. network policies or an upstream gateway) until patched. Audit clusters for Ingresses combining these two annotations to identify which protected routes may be exposed to unauthenticated access.

9.3
group max
  • Traefik Labs Traefik Proxy (Kubernetes ingress-nginx provider) >= v3.7.0 and <= v3.7.11 (fixed in v3.7.12; Traefik v2 and v3 releases before v3.7.0 not affected)
moderateon the order of 1,000-10,000 deployments realistically affected (exact count unknown)
CVE-2026-85595
+3 in the same advisory: …85597 …85596 …85594
Authentication Bypass in Traefik digestAuth Middleware

Traefik's digestAuth middleware mishandles unknown usernames: instead of rejecting the request, it derives a digest from an empty secret, which lets attackers compute a valid digest response using completely arbitrary credentials. An attacker who can reach any route protected by digestAuth therefore authenticates without knowing a valid username or password. Successful bypass grants unauthenticated access to whatever backend services those routes protect, such as internal APIs, dashboards, or admin panels. Only Traefik deployments that actually configure the digestAuth middleware are affected, running versions in the 2.x line before v2.11.55 or versions v3.0.0 through v3.7.10. No exploitation has been observed: there is no public proof-of-concept, the flaw is not in CISA KEV, and EPSS estimates a 0.4% probability of exploitation within 30 days.

Do: Upgrade to Traefik v2.11.55 or later on the 2.x line and to a 3.x release newer than v3.7.10. Audit configurations for digestAuth middleware usage and, as an interim mitigation, switch affected routes to basicAuth or another authentication mechanism or restrict their network exposure. Since no public PoC exists yet, prioritize internet-facing Traefik instances that expose digestAuth-protected routes.

9.3
group max
<1% PoC
  • Traefik Labs Traefik Proxy 2.x before v2.11.55
  • Traefik Labs Traefik Proxy v3.0.0 through v3.7.10
moderatelikely thousands to tens of thousands of deployments (the digestAuth-using subset of Traefik's large install base)