Traefik's HTTP Auth Bypass: Check Every Route to Your Backend

You check an application's HTTPS URL, see an authentication challenge, and mark the deployment protected. That conclusion depends on every other route to the backend enforcing the same boundary. A second entry point can invalidate it without changing the page you tested.

The October 7 Traefik advisory

GHSA-qvj7-gq9c-hp7q affects Traefik 3.7.13's Kubernetes Ingress NGINX provider. For an Ingress with SSL passthrough enabled, a generated HTTP router could forward to the backend without applying authentication or source-allowlist annotations. A reachable HTTP entry point could therefore expose a protected backend to an unauthenticated client. Read the Traefik advisory.

The fix is in 3.7.14. The maintainers state that Traefik v2 and v3 releases before 3.7.13 are unaffected by this specific issue. This is a defect in Traefik's compatibility provider, not a claim that every Kubernetes ingress controller bypasses authentication. The update also changes generated router names, which operators should account for during migration.

Test the route that an outsider can actually reach

Configuration review tells you what you intended. An external request tells you what the deployed system does. Both are useful, especially when a controller generates routers from annotations and several teams can create ingress objects.

Build an inventory of the application's hostnames and listening ports. For each intended entry point, record whether an anonymous request should be redirected, rejected, or served public content. Check both the initial response and the final destination. A redirect is not a substitute for examining whether another route serves the protected content directly.

Close the route and keep it closed

1. Check the deployed Traefik image and whether the affected provider and passthrough configuration are in use. Upgrade affected installations to 3.7.14 or a later supported release containing the fix.
2. Review generated routers after deployment, including authentication middleware, allowlists, entry points, and router names used by your operational tooling.
3. Test anonymous and authorized access through each intended route. Use a harmless protected test resource so the result is unambiguous.
4. Remove unnecessary entry points and direct backend exposure. Keep authorization in the application for sensitive operations as well as at the edge.

How BlackSight helps find the overlooked entry point

BlackSight's port scan can reveal a reachable service you omitted from the original HTTPS check. Add relevant HTTP and HTTPS URLs as explicit scan targets so web and API checks examine the intended entry points. The headers scan also helps review the browser-facing policy delivered by those services.

This is a useful place for recurring scans after infrastructure changes: an unexpected service or publicly visible response gives the team something concrete to investigate. A scan does not know that a particular dashboard was intended to be private, so compare observed behavior with the access policy you recorded. We are not claiming a dedicated BlackSight check for this advisory.

Keep the patch record, anonymous-access results, and updated scan report together. That combination demonstrates both the software change and its external effect. Our HTTP security headers guide covers an additional layer to verify once the routing and authentication boundary is correct.