Update module github.com/traefik/traefik/v3 to v3.6.21 [SECURITY]#2388
Merged
avnes merged 2 commits intoJul 6, 2026
Merged
Conversation
Contributor
Author
|
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
Contributor
Author
Edited/Blocked NotificationRenovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR. You can manually request rebase by checking the rebase/retry box above. |
avnes
approved these changes
Jul 6, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
v3.6.17→v3.6.21Traefik has a StripPrefix Route-Level Auth Bypass via Path Normalization
CVE-2026-48020 / GHSA-xf64-8mw2-4gr2
More information
Details
Summary
There is a high severity vulnerability in Traefik's
StripPrefixmiddleware that allows an unauthenticated attacker to bypass route-level authentication and authorization. When a public router matches on aPathPrefixrule and applies theStripPrefixmiddleware, a request path containing..or its percent-encoded form%2e%2ecan match the public route at routing time and then, after the prefix is stripped and the path is normalized, resolve to a path served by a separate, authenticated router. As a result, an attacker can reach protected backend paths — such as admin or internal configuration endpoints — without satisfying the authentication middleware attached to the protected router.Patches
For more information
If there are any questions or comments about this advisory, please open an issue.
Original Description
Traefik StripPrefix Route-Level Auth Bypass via Path Normalization (/api../)
Summary
A route-level authentication/authorization bypas was found in Traefik when
PathPrefix-based public routes are combined withStripPrefix.A request using
/api../or/api%2e%2e/can avoid protected router rules at the routing stage, but afterStripPrefix, the path is normalized and forwarded to the backend as a protected path such as/adminor/internal/config.This is reproducible on patched/latest Traefik versions and appears related to, but distinct from, previously disclosed
StripPrefixRegex/ path-normalization issues.This report specifically affects
StripPrefix.Affected Versions Tested
traefik:v2.11v2.11.46traefik:v3.6v3.6.17traefik:latestv3.7.1Lab Contrast
traefik:v2.10traefik:v3.5Vulnerable Configuration Pattern
The issue appears when:
Observed Behavior
Direct Protected Paths
These are correctly blocked.
GET /admin401GET /internal/config401Expected Public Exclusions
These do not expose protected backend paths.
GET /api/admin404GET /api/internal/config404Bypass Payloads
These reach protected backend paths.
GET /api../admin200/adminGET /api%2e%2e/admin200/adminGET /api../internal/config200/internal/configGET /api%2e%2e/internal/config200/internal/configMinimal PoC
docker-compose.yml
dynamic.yml
backend.py
poc.py
Run
Expected Vulnerable Output
Root Cause Hypothesis
The vulnerable behavior appears to be caused by path normalization after prefix stripping.
The request does not match the protected
/adminrouter at the routing stage, but the backend receives/adminafter normalization.The relevant behavior appears related to
StripPrefixcallingreq.URL.JoinPath()after removing the prefix in newer versions.Security Impact
An unauthenticated network attacker can bypass intended Traefik route-level authentication/authorization boundaries and access backend paths that the operator intended to protect with a separate protected router.
Potential impact includes:
In the local lab, a protected
/admin/execendpoint was reachable through/api../admin/exec, demonstrating a conditional RCE chain when the backend contains an execution primitive.This is not a standalone Traefik RCE claim. It is an authentication/authorization boundary bypass that can expose protected backend functionality.
Suggested Severity
Suggested CVSS is 10.0 Critical with Scope Changed, because the bypass crosses the Traefik route-level authorization boundary and exposes protected backend functionality.
Scope Changed was selected because the request bypasses Traefik's route-level authorization boundary and reaches backend paths that are intended to be protected by a separate authenticated router.
If the vendor treats Traefik and the backend as the same security scope, the score may be interpreted as 9.1 Critical with Scope Unchanged:
The issue was submitted with the stronger Scope Changed interpretation, but the maintainers may adjust the final CVSS score during triage.
Weakness
Primary CWE:
CWE-863: Incorrect AuthorizationRelated weakness candidates:
CWE-180: Incorrect Behavior Order: Validate Before CanonicalizeCWE-22: Improper Limitation of a Pathname to a Restricted DirectoryMitigation Verified in Lab
The bypass was blocked when using a stricter prefix boundary:
or:
Relation to Existing Advisories
This appears related to the same vulnerability family as prior Traefik path normalization /
StripPrefixRegexbypass advisories, but it affectsStripPrefixand remains reproducible on patched/latest versions tested above.This was reported as a possible incomplete fix or bypass variant rather than assuming it is a duplicate.
Reporter
WonYun / kyun0
Severity
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Traefik: Kubernetes Gateway crossProviderNamespaces bypass allows HTTPRoute outside the allowlist to expose internal Traefik services
CVE-2026-54761 / GHSA-3g6v-2r68-prfc
More information
Details
Summary
There is a high severity vulnerability in Traefik's Kubernetes Gateway provider affecting the
crossProviderNamespacesallowlist. ForHTTPRouterules that declare multiple (WRR) backendRefs, Traefik evaluates the allowlist against the targetbackendRef.namespaceinstead of the route's own namespace. As a result, anHTTPRoutecreated in a namespace that is not allow-listed can reference a cross-providerTraefikServicesuch asapi@internal,dashboard@internalorrest@internalby pointingbackendRef.namespaceat an allow-listed namespace covered by a Gateway APIReferenceGrant, exposing internal Traefik services on the data plane. Exploitation requires the ability to create an acceptedHTTPRouteand a matchingReferenceGrantfrom an allow-listed namespace ; it does not require any change to Traefik static configuration, RBAC, or the deployment itself.Patches
For more information
If you have any questions or comments about this advisory, please open an issue.
Original Description
Summary
The Kubernetes Gateway provider's
crossProviderNamespacesoption is documented as restricting which Gateway API route namespaces may declareTraefikServicebackendRefs.For
HTTPRouterules with multiple backendRefs, Traefik checks this allowlist againstbackendRef.namespaceinstead of theHTTPRoutenamespace. A route in a namespace that is not allow-listed can therefore addapi@internalto the generated WRR service by settingbackendRef.namespaceto an allow-listed namespace, as long as a normal Gateway APIReferenceGrantpermits that cross-namespace reference.Verified affected versions:
v3.7.1(fa49e2bcad7ffd8a80accdf1fae1ae480913d93d)29406d42898547f1ffabd904f66af06c212740cf)Expected Behavior
With:
only Gateway API routes whose own namespace is
trustedshould be allowed to declareTraefikServicebackendRefs such asapi@internal,dashboard@internal, orrest@internal.An
HTTPRoutein namespaceattackershould not be able to expose an internal Traefik service by setting:Actual Behavior
For an
HTTPRoutein namespaceattackerwith two backendRefs, Traefik generates a WRR service containing:even though
crossProviderNamespacesonly allowstrusted.Threat Model
This does not require changing Traefik static configuration or Traefik process state. The relevant boundary is the Kubernetes Gateway provider's
crossProviderNamespacespolicy: namespaces outside the allowlist should not be able to declare cross-providerTraefikServicebackendRefs.The precondition is a Gateway API environment where an untrusted or less-trusted namespace can create
HTTPRouteobjects accepted by a Gateway, and a namespace in thecrossProviderNamespacesallowlist has a matchingReferenceGrant.ReferenceGrantshould 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
ReferenceGrantshould be treated as necessary but not sufficient for this case. It authorizes the cross-namespace object reference under Gateway API rules, but Traefik'scrossProviderNamespacesoption is an additional Traefik-specific security control for cross-providerTraefikServicebackendRefs, especially@internalservices. Therefore aReferenceGrantfromtrustedmust not make a route inattackerequivalent to a route whose own namespace istrusted.Required Attacker Capability
Required:
HTTPRoutein namespaceattacker;HTTPRouteaccepted by aGateway;ReferenceGrantfrom an allow-listed namespace, or on a delegated namespace setup where suchReferenceGrantobjects are managed separately from Traefik's provider configuration.Not required:
providers.kubernetesGateway.crossProviderNamespaces;api.insecure;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:
The migration notes also describe the security reason for the option:
and the documented behavior is:
The provider struct uses the same route-namespace wording:
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
kindcluster with Traefikv3.7.1, real Gateway API CRDs, real KubernetesGateway,HTTPRoute, andReferenceGrantresources, and HTTP requests to Traefik's normalwebentrypoint.The complete local reproducer I used is a self-contained
kindPoC with these files:Run command:
The script creates a local
kindcluster, loads localtraefik:v3.7.1andtraefik/whoami:v1.11.0images, installs Gateway API CRDs, deploys Traefik and the PoC Gateway resources, sends the control and exploitcurlrequests to127.0.0.1:18080, prints route status, and deletes the cluster on exit.Traefik was started with:
The local host entrypoint was:
The target namespace has a normal Gateway API
ReferenceGrant:Positive control:
Bypass:
Observed external result:
The
HTTPRoutestatus shows the boundary difference:This is the externally visible security failure: the same route namespace and same
api@internalbackendRef 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
kindPoC above is the primary impact reproduction.Files:
probe/crossprovider_namespace_probe_test.goprobe/cross_provider_namespace_probe.ymlprobe/cross_provider_namespace_single_control.ymlReproduction:
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 -vObserved output on both tested versions:
The reproducer also includes a positive control:
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:
The mixed/multiple backendRef path calls
loadService. InloadService,namespaceis overwritten frombackendRef.Namespace, then passed toloadHTTPBackendRef:loadHTTPBackendRefthen checkscrossProviderNamespacesagainst this target 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
HTTPRoutedespite being excluded fromcrossProviderNamespaces.Potentially exposed internal services include:
api@internaldashboard@internalrest@internalThis is a route isolation / internal service exposure / security option bypass. Practical severity depends on whether internal services are enabled and how Gateway
ReferenceGrantdelegation is used, but the observed behavior violates the documented security boundary ofcrossProviderNamespaces.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:
When a router on the normal web entrypoint references
api@internal, the same API endpoint becomes unauthenticated:A WRR service containing
api@internalalso exposes the API:This is the security consequence of the provider bug: a namespace that should be blocked by
crossProviderNamespacescan make Traefik generate a service graph containingapi@internalon a route it controls.Suggested Fix
For Gateway
HTTPRouteTraefikServicecross-provider backendRefs, validatecrossProviderNamespacesagainstroute.Namespacein all code paths, including mixed/WRR backendRefs.Severity
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Release Notes
traefik/traefik (github.com/traefik/traefik/v3)
v3.6.21Compare Source
All Commits
Bug fixes:
v3.6.20Compare Source
All Commits
Bug fixes:
v3.6.19Compare Source
All Commits
Bug fixes:
11d2514(#13227 @rtribotte)Documentation:
v3.6.18Compare Source
All Commits
Release canceled.
Configuration
📅 Schedule: (UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by Renovate Bot.