CVE-2026-54765: Traefik Gateway Auth Bypass Vulnerability

CVE-2026-54765 Overview

CVE-2026-54765 affects Traefik, an open source HTTP reverse proxy and load balancer widely deployed as a Kubernetes ingress controller. The flaw exists in Traefik's Kubernetes Gateway API provider from v3.7.0 prior to v3.7.6. Two accepted HTTPRoute resources targeting the same backend Service:port but configuring different backendRef filters collapse to the same child service. Only one route's filter set is then applied to all requests reaching that backend. The issue is tracked as an improper access control weakness [CWE-284] and is fixed in Traefik v3.7.6.

Critical Impact
An attacker who can create an accepted HTTPRoute sharing the same backend Service:port may cause their filter context, including security-sensitive headers such as tenant identity or authorization values, to be applied to another route's requests, potentially crossing namespace boundaries where a ReferenceGrant permits cross-namespace targeting.

Affected Products

Traefik v3.7.0 through v3.7.5
Traefik Kubernetes Gateway API provider (HTTPRoute and GRPCRoute handling)
Multi-tenant Kubernetes clusters using Traefik as a Gateway API implementation

Discovery Timeline

2026-07-06 - CVE-2026-54765 published to NVD
2026-07-08 - Last updated in NVD database

Technical Details for CVE-2026-54765

Vulnerability Analysis

The vulnerability resides in Traefik's Kubernetes Gateway API provider, specifically the code paths that translate HTTPRoute and GRPCRoute resources into dynamic router and service configurations. When two accepted routes target the same backend Service:port, Traefik generates a child service name that collides between the routes. The provider then keeps only one route's backendRef filters and applies that filter set to traffic entering the shared backend.

In Gateway deployments where backendRef filters inject security-sensitive request headers, the collision breaks the trust boundary between routes. Filters that set tenant identifiers, authorization context, or headers consumed by the backend can be overwritten by an attacker-controlled route. Because Gateway API supports cross-namespace targeting via ReferenceGrant, a hostile route in one namespace can influence traffic bound for a backend in another namespace when a grant is in place.

Root Cause

The root cause is a name collision in the internal service identifier that Traefik derives for each backendRef. Prior to the fix, the identifier was computed from the backend reference alone and did not incorporate the originating route or the index of the backendRef within its rule. Two distinct routes referring to the same Service:port therefore mapped to the same dynamic service object, and only one route's filter chain survived reconciliation.

Attack Vector

Exploitation requires an attacker who can create or modify a Gateway API HTTPRoute resource that the Gateway accepts. The attacker defines a route sharing the same backend Service:port as a victim route and sets backendRef filters that inject or overwrite headers the backend trusts. Once Traefik reconciles the routes, the attacker's filter context is applied to requests arriving through the victim route.

// Patch: pkg/provider/kubernetes/gateway/httproute.go
// The loop now passes routeKey and the backendRef index (bi)
// so generated service names uniquely bind to their originating route.

var wrr dynamic.WeightedRoundRobin
var condition *metav1.Condition
for bi, backendRef := range routeRule.BackendRefs {
    // TODO in loadService we need to always return a non-nil serviceName even when there is an error which is not the
    // usual defacto.
    svcName, errCondition := p.loadService(ctx, listener, conf, routeKey, route, bi, backendRef, pathMatch)
    weight := ptr.To(int(ptr.Deref(backendRef.Weight, 1)))
    if errCondition != nil {
        log.Ctx(ctx).Error().

Source: Traefik commit 8aada7a. The equivalent fix is applied to grpcroute.go, threading routeKey and the backendRef index into loadGRPCBackendRef so that generated service names no longer collide across routes.

Detection Methods for CVE-2026-54765

Indicators of Compromise

Multiple accepted HTTPRoute or GRPCRoute resources targeting the same backend Service:port with divergent filters blocks.
Backend application logs showing unexpected values in trusted headers such as tenant, user identity, or authorization context.
Presence of ReferenceGrant resources permitting cross-namespace backendRef targeting to sensitive Services.

Detection Strategies

Inventory all HTTPRoute and GRPCRoute objects in the cluster and group them by backendRef target; flag any group containing more than one route with filters defined.
Review the Traefik dynamic configuration output for services whose weighted round-robin members map back to more than one Gateway API route.
Correlate Kubernetes audit logs for HTTPRoute create and update events against the set of routes that reach shared backends.

Monitoring Recommendations

Alert on creation of HTTPRoute resources by service accounts that should not manage ingress routing.
Monitor backend applications for header values that were previously constant but begin varying after new routes are deployed.
Track Traefik version at the pod and Helm chart level to ensure clusters run v3.7.6 or later.

How to Mitigate CVE-2026-54765

Immediate Actions Required

Upgrade Traefik to v3.7.6 or later on all clusters using the Kubernetes Gateway API provider.
Audit existing HTTPRoute and GRPCRoute resources for shared Service:port targets and remove untrusted routes until the upgrade is complete.
Restrict RBAC permissions for HTTPRoute, GRPCRoute, and ReferenceGrant resources to trusted namespaces and identities.

Patch Information

The fix is delivered in Traefik v3.7.6. The patch, applied in commit 8aada7a7d52e4588a75386d8b86d270f6fe8d549, threads the originating route key and backendRef index into service name generation for both HTTPRoute and GRPCRoute, eliminating the collision. See the GitHub Security Advisory GHSA-6p8f-p8j2-rqmv and the Traefik v3.7.6 release notes for full details.

Workarounds

Ensure that at most one accepted HTTPRoute or GRPCRoute targets any given backend Service:port until upgrading.
Remove backendRef filters that set security-sensitive headers and enforce those headers at the backend or a dedicated policy layer instead.
Revoke or narrow ReferenceGrant resources that permit cross-namespace backendRef targeting to sensitive Services.

bash

# Verify installed Traefik version in the cluster
kubectl get pods -A -l app.kubernetes.io/name=traefik \
  -o jsonpath='{range .items[*]}{.metadata.namespace}{"/"}{.metadata.name}{"\t"}{.spec.containers[*].image}{"\n"}{end}'

# Identify HTTPRoutes sharing a backend Service:port
kubectl get httproutes -A -o json | \
  jq -r '.items[] | .metadata.namespace as $ns | .metadata.name as $n |
         .spec.rules[]?.backendRefs[]? |
         [$ns, $n, .name, (.port|tostring)] | @tsv' | \
  sort -k3,4 | uniq -f2 -D

# Upgrade Traefik via Helm to the fixed release
helm repo update
helm upgrade traefik traefik/traefik --version 3.7.6 -n traefik