Common Weakness Enumeration

CWE-863

Allowed-with-Review

Incorrect Authorization

Abstraction: Class · Status: Incomplete

API response cwe.mitre.org

The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.

7172 vulnerabilities reference this CWE, most recent first.

GHSA-6M7H-74WG-GQ59

Vulnerability from github – Published: 2022-01-15 00:01 – Updated: 2022-07-15 00:00
VLAI
Details

An issue has recently been discovered in Arista EOS where the incorrect use of EOS's AAA API’s by the OpenConfig and TerminAttr agents could result in unrestricted access to the device for local users with nopassword configuration.

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-28501"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-01-14T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "An issue has recently been discovered in Arista EOS where the incorrect use of EOS\u0027s AAA API\u2019s by the OpenConfig and TerminAttr agents could result in unrestricted access to the device for local users with nopassword configuration.",
  "id": "GHSA-6m7h-74wg-gq59",
  "modified": "2022-07-15T00:00:16Z",
  "published": "2022-01-15T00:01:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-28501"
    },
    {
      "type": "WEB",
      "url": "https://www.arista.com/en/support/advisories-notices/security-advisories/13449-security-advisory-0071"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6MHR-52MV-6V6F

Vulnerability from github – Published: 2022-10-18 17:12 – Updated: 2022-10-18 17:12
VLAI
Summary
Field-level access-control bypass for multiselect field
Details

Impact

@keystone-6/core@2.2.0 || 2.3.0 users who are using the multiselect field, and provided field-level access control - are vulnerable to their field-level access control not being used.

List-level access control is NOT affected.

Field-level access control for fields other than multiselect are NOT affected.

Example, you are vulnerable if you are using field-level access control on a multiselect like the following:

const yourList = list({
  access: {
    // this is list-level access control, this is NOT impacted
  },
  fields: {
    yourFieldName: multiselect({
      // this is field-level access control, for multiselect fields
      //   this is vulnerable
      access: {
        create: ({ session }) => session?.data.isAdmin,
        update: ({ session }) => session?.data.isAdmin,
      },
      options: [
        { value: 'apples', label: 'Apples' },
        { value: 'oranges', label: 'Oranges' },
      ],
      // ...
    }),
    // ...
  },
  // ...
});

Mitigation

Please upgrade to @keystone-6/core >= 2.3.1, where this vulnerability has been closed.

Workarounds

If for some reason you cannot upgrade your dependencies, you should stop using the multiselect field.

Credits

Thanks to Marek R for reporting and submitting the pull request to fix this problem.

If you have any questions around this security advisory, please don't hesitate to contact us at security@keystonejs.com, or open an issue on GitHub.

If you have a security flaw to report for any software in this repository, please see our SECURITY policy.

Severity
9.1 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@keystone-6/core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.2.0"
            },
            {
              "fixed": "2.3.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-39322"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-10-18T17:12:46Z",
    "nvd_published_at": "2022-10-25T17:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "#### Impact\n\n`@keystone-6/core@2.2.0 || 2.3.0` users who are using the `multiselect` field, and provided field-level access control - are vulnerable to their field-level access control not being used.\n\nList-level access control is **NOT** affected.\n\nField-level access control for fields other than `multiselect` are **NOT** affected.\n\nExample, **you are vulnerable if** you are using field-level access control on a `multiselect` like the following:\n```ts\nconst yourList = list({\n  access: {\n    // this is list-level access control, this is NOT impacted\n  },\n  fields: {\n    yourFieldName: multiselect({\n      // this is field-level access control, for multiselect fields\n      //   this is vulnerable\n      access: {\n        create: ({ session }) =\u003e session?.data.isAdmin,\n        update: ({ session }) =\u003e session?.data.isAdmin,\n      },\n      options: [\n        { value: \u0027apples\u0027, label: \u0027Apples\u0027 },\n        { value: \u0027oranges\u0027, label: \u0027Oranges\u0027 },\n      ],\n      // ...\n    }),\n    // ...\n  },\n  // ...\n});\n```\n\n#### Mitigation\nPlease upgrade to `@keystone-6/core \u003e= 2.3.1`, where this vulnerability has been closed.\n\n#### Workarounds\nIf for some reason you cannot upgrade your dependencies, you should stop using the `multiselect` field.\n\n#### Credits\nThanks to [Marek R](https://github.com/marekryb) for reporting and submitting the pull request to fix this problem.\n\nIf you have any questions around this security advisory, please don\u0027t hesitate to contact us at [security@keystonejs.com](mailto:security@keystonejs.com), or [open an issue on GitHub](https://github.com/keystonejs/keystone/issues/new/choose).\n\nIf you have a security flaw to report for any software in this repository, please see our [SECURITY policy](https://github.com/keystonejs/keystone/blob/main/SECURITY.md).",
  "id": "GHSA-6mhr-52mv-6v6f",
  "modified": "2022-10-18T17:12:46Z",
  "published": "2022-10-18T17:12:46Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/keystonejs/keystone/security/advisories/GHSA-6mhr-52mv-6v6f"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39322"
    },
    {
      "type": "WEB",
      "url": "https://github.com/keystonejs/keystone/commit/65c6ee3deef23605fc72b80230908696a7a65e7c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/keystonejs/keystone"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Field-level access-control bypass for multiselect field"
}

GHSA-6MWH-463X-C3V4

Vulnerability from github – Published: 2022-02-25 00:01 – Updated: 2023-08-08 15:31
VLAI
Details

An incorrect access control issue in HMS v1.0 allows unauthenticated attackers to read and modify all PHP files.

Severity
9.1 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-25402"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-02-24T15:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "An incorrect access control issue in HMS v1.0 allows unauthenticated attackers to read and modify all PHP files.",
  "id": "GHSA-6mwh-463x-c3v4",
  "modified": "2023-08-08T15:31:44Z",
  "published": "2022-02-25T00:01:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-25402"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dota-st/Vulnerability/blob/master/HMS/HMS.md"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6MXQ-JR92-3H2R

Vulnerability from github – Published: 2026-07-22 12:32 – Updated: 2026-08-05 21:49
Withdrawn 2026-08-05 VLAI
Summary
Duplicate Advisory: Traefik Gateway API HTTPRoute BackendRef ExtensionRef Namespace Confusion
Details

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-qq9q-x9w4-chhj. This link is maintained to preserve external references.

Original Description

Traefik versions 3.7.0 through 3.7.6 contain a namespace confusion vulnerability in the Kubernetes Gateway API provider. When resolving HTTPRoute.spec.rules[].backendRefs[].filters[].extensionRef, Traefik used the backend Service namespace instead of the HTTPRoute namespace. A low-privileged route author holding a ReferenceGrant for a cross-namespace Service could therefore bind a Traefik Middleware from the backend namespace without a separate grant for that middleware, potentially injecting trusted reverse-proxy identity headers into downstream requests. The issue is fixed in version 3.7.7.

Severity
5.3 (Medium)
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c 3.7.7"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/traefik/traefik"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-05T21:49:07Z",
    "nvd_published_at": "2026-07-22T12:18:20Z",
    "severity": "MODERATE"
  },
  "details": "## Duplicate Advisory\n\nThis advisory has been withdrawn because it is a duplicate of\u00a0GHSA-qq9q-x9w4-chhj. This link is maintained to preserve external references.\n\n## Original Description\nTraefik versions 3.7.0 through 3.7.6 contain a namespace confusion vulnerability in the Kubernetes Gateway API provider. When resolving HTTPRoute.spec.rules[].backendRefs[].filters[].extensionRef, Traefik used the backend Service namespace instead of the HTTPRoute namespace. A low-privileged route author holding a ReferenceGrant for a cross-namespace Service could therefore bind a Traefik Middleware from the backend namespace without a separate grant for that middleware, potentially injecting trusted reverse-proxy identity headers into downstream requests. The issue is fixed in version 3.7.7.",
  "id": "GHSA-6mxq-jr92-3h2r",
  "modified": "2026-08-05T21:49:07Z",
  "published": "2026-07-22T12:32:18Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/security/advisories/GHSA-qq9q-x9w4-chhj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-65601"
    },
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/commit/26c96a3935cafb473f4a5bae1886560d9aa4e4f0"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/traefik-before-namespace-confusion-via-httproute-extensionref"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Duplicate Advisory: Traefik Gateway API HTTPRoute BackendRef ExtensionRef Namespace Confusion",
  "withdrawn": "2026-08-05T21:49:07Z"
}

GHSA-6P2H-RJJ7-2J63

Vulnerability from github – Published: 2022-09-02 00:01 – Updated: 2024-05-14 21:21
VLAI
Summary
openstack-barbican Denial of Service vulnerability
Details

An authorization flaw was found in openstack-barbican, where anyone with an admin role could add secrets to a different project container. This flaw allows an attacker on the network to consume protected resources and cause a denial of service.

Severity
4.9 (Medium)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "barbican"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-23452"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-05-14T21:21:48Z",
    "nvd_published_at": "2022-09-01T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An authorization flaw was found in openstack-barbican, where anyone with an admin role could add secrets to a different project container. This flaw allows an attacker on the network to consume protected resources and cause a denial of service.",
  "id": "GHSA-6p2h-rjj7-2j63",
  "modified": "2024-05-14T21:21:48Z",
  "published": "2022-09-02T00:01:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23452"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openstack/barbican/commit/6c841b23afa8ed6fa4cd01ba1a6bebfb60f06ae5"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2022:5114"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2022:8874"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2022-23452"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2022908"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2025090"
    },
    {
      "type": "WEB",
      "url": "https://review.opendev.org/c/openstack/barbican/+/814200"
    },
    {
      "type": "WEB",
      "url": "https://storyboard.openstack.org/#!/story/2009297"
    },
    {
      "type": "WEB",
      "url": "https://storyboard.openstack.org/#%21/story/2009297"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "openstack-barbican Denial of Service vulnerability"
}

GHSA-6P2V-36C6-F6M5

Vulnerability from github – Published: 2026-08-05 06:30 – Updated: 2026-08-05 06:30
VLAI
Details

In OpenStack Swift through 2.38.0, the S3API middleware does not sanitize Swift-native control headers (X-Copy-From, X-Copy-From-Account) from S3 API requests when s3_acl=true. An attacker can inject these headers into a signed PUT request targeting their own bucket, causing Swift to perform a server-side copy from another tenant's private object. The source object authorization is bypassed because the S3API middleware has already authorized the request against the destination. The attacker can read any object whose project_id, container name, and object name are known, regardless of the source object's ACLs or ownership. This requires the non-default s3_acl=true configuration.

Severity
6.0 (Medium)
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-71192"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-05T06:16:40Z",
    "severity": "MODERATE"
  },
  "details": "In OpenStack Swift through 2.38.0, the S3API middleware does not sanitize Swift-native control headers (X-Copy-From, X-Copy-From-Account) from S3 API requests when s3_acl=true. An\nattacker can inject these headers into a signed PUT request targeting their own bucket, causing Swift to perform a server-side copy from another tenant\u0027s private object. The source object authorization is bypassed because the S3API middleware has already authorized the request against the destination. The attacker can read any object whose project_id, container name, and object name are known, regardless of the source object\u0027s ACLs or ownership. This requires the non-default s3_acl=true configuration.",
  "id": "GHSA-6p2v-36c6-f6m5",
  "modified": "2026-08-05T06:30:33Z",
  "published": "2026-08-05T06:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-71192"
    },
    {
      "type": "WEB",
      "url": "https://launchpad.net/bugs/2158733"
    },
    {
      "type": "WEB",
      "url": "https://openwall.com/lists/oss-security/2026/07/28/26"
    },
    {
      "type": "WEB",
      "url": "https://security.openstack.org/ossa/OSSA-2026-030.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-6P54-FW2F-Q7GF

Vulnerability from github – Published: 2026-06-11 20:26 – Updated: 2026-07-15 21:58
VLAI
Summary
DevGuard has improper authorization on public assets
Details

Impact

On a DevGuard API instance with one or more public assets, any authenticated user — including users from a different organization with no membership or role in the affected org/project — can create, update, reapply, and delete VEX rules on those public assets. The same flaw affects the other vulnerability-triage write endpoints exposed under a public asset, including:

  • VEX rule create / update / reapply / delete
  • Dependency-vuln event creation (accept / reject / mitigate decisions), batch event creation, vuln sync, and mitigation
  • License risk creation
  • External reference writes
  • Artifact creation and license refresh

The attacker needs a valid account on the instance, but no membership in the victim organization, project, or asset is required.

Security impact is primarily to integrity of the vulnerability picture of public assets: an attacker can mark CVEs as false-positive, silence vulnerabilities, attach misleading justifications, or delete legitimate triage rules — undermining the trustworthiness of every consumer of the affected asset's VEX/SBOM output. Because public assets are by definition consumed by third parties (downstream users, supply-chain consumers, the published vex.json/sbom.json), the blast radius extends to anyone relying on that data.

Private assets are not affected by this advisory: the public-read exemption that enables the bypass does not apply to them, and access remains correctly gated by organization/project membership. The private setting is only relevant in DevGuard itself — there is no impact given when you have an open-source project on e.g. GitLab/GitHub and a private DevGuard asset connected.

Patches

Version v1.4.2contains a patch. Users should upgrade to the patched release as soon as it is available.

Workarounds

If developers cannot upgrade their applications immediately:

  • ** They should make affected assets non-public.** In the asset settings, switch visibility from public to private. This removes the public-read exemption in the access-control middleware and restores correct authorization on all write endpoints for that asset. Downstream consumers that previously relied on the public vex.json / sbom.json endpoints will need to be granted explicit access or must receive an exported file version until the patched release is deployed.

Resources

Fixed commit: https://github.com/l3montree-dev/devguard/commit/1be88ec1309a5dc0566e35a23bdc4ea3ecd11417

Credit

DeevGuard thanks @philipflohr (awesome-it.de) for finding and responsibly reporting this vulnerability!

Severity
7.1 (High)
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:H/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/l3montree-dev/devguard"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48089"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-11T20:26:18Z",
    "nvd_published_at": "2026-06-19T20:16:16Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nOn a DevGuard API instance with one or more **public assets**, any authenticated user \u2014 including users from a different organization with no membership or role in the affected org/project \u2014 can create, update, reapply, and delete **VEX rules** on those public assets. The same flaw affects the other vulnerability-triage write endpoints exposed under a public asset, including:\n\n- VEX rule create / update / reapply / delete\n- Dependency-vuln event creation (accept / reject / mitigate decisions), batch event creation, vuln sync, and mitigation\n- License risk creation\n- External reference writes\n- Artifact creation and license refresh\n\nThe attacker needs a valid account on the instance, but no membership in the victim organization, project, or asset is required.\n\n**Security impact** is primarily to **integrity** of the vulnerability picture of public assets: an attacker can mark CVEs as false-positive, silence vulnerabilities, attach misleading justifications, or delete legitimate triage rules \u2014 undermining the trustworthiness of every consumer of the affected asset\u0027s VEX/SBOM output. Because public assets are by definition consumed by third parties (downstream users, supply-chain consumers, the published vex.json/sbom.json), the blast radius extends to anyone relying on that data.\n\nPrivate assets are **not affected** by this advisory: the public-read exemption that enables the bypass does not apply to them, and access remains correctly gated by organization/project membership. The private setting is only relevant in DevGuard itself \u2014  there is no impact given when you have an open-source project on e.g. GitLab/GitHub and a private DevGuard asset connected.\n\n### Patches\n\nVersion `v1.4.2`contains a patch. Users should upgrade to the patched release as soon as it is available.\n\n### Workarounds\n\nIf developers cannot upgrade their applications immediately:\n\n- ** They should make affected assets non-public.** In the asset settings, switch visibility from public to private. This removes the public-read exemption in the access-control middleware and restores correct authorization on all write endpoints for that asset. Downstream consumers that previously relied on the public `vex.json` / `sbom.json` endpoints will need to be granted explicit access or must receive an exported file version until the patched release is deployed.\n\n### Resources\nFixed commit: https://github.com/l3montree-dev/devguard/commit/1be88ec1309a5dc0566e35a23bdc4ea3ecd11417\n\n### Credit\n\nDeevGuard thanks @philipflohr ([awesome-it.de](https://awesome-it.de/)) for finding and responsibly reporting this vulnerability!",
  "id": "GHSA-6p54-fw2f-q7gf",
  "modified": "2026-07-15T21:58:25Z",
  "published": "2026-06-11T20:26:18Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/l3montree-dev/devguard/security/advisories/GHSA-6p54-fw2f-q7gf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48089"
    },
    {
      "type": "WEB",
      "url": "https://github.com/l3montree-dev/devguard/commit/1be88ec1309a5dc0566e35a23bdc4ea3ecd11417"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/l3montree-dev/devguard"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:H/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "DevGuard has improper authorization on public assets"
}

GHSA-6P5J-FMWW-GQ26

Vulnerability from github – Published: 2023-08-11 03:30 – Updated: 2024-04-04 06:51
VLAI
Details

Improper access control in firmware for some Intel(R) PROSet/Wireless WiFi software for Windows before version 22.220 HF (Hot Fix) may allow a privileged user to potentially enable escalation of privilege via local access.

Severity
8.2 (High)
CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-28714"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-08-11T03:15:25Z",
    "severity": "MODERATE"
  },
  "details": "Improper access control in firmware for some Intel(R) PROSet/Wireless WiFi software for Windows before version 22.220 HF (Hot Fix) may allow a privileged user to potentially enable escalation of privilege via local access.",
  "id": "GHSA-6p5j-fmww-gq26",
  "modified": "2024-04-04T06:51:15Z",
  "published": "2023-08-11T03:30:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28714"
    },
    {
      "type": "WEB",
      "url": "http://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00872.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6P6J-F8Q6-5R72

Vulnerability from github – Published: 2025-06-09 15:31 – Updated: 2025-10-06 21:30
VLAI
Details

Incorrect authorization vulnerability in TCMAN's GIM v11. This vulnerability allows an unprivileged attacker to modify the permissions held by each of the application's users, including the user himself by sending a POST request to /PC/Options.aspx?Command=2&Page=-1.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N
7.1 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-40669"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-09T13:15:22Z",
    "severity": "HIGH"
  },
  "details": "Incorrect authorization vulnerability in TCMAN\u0027s GIM v11. This vulnerability allows an unprivileged attacker to modify the permissions held by each of the application\u0027s users, including the user himself by sending a POST request to /PC/Options.aspx?Command=2\u0026amp;Page=-1.",
  "id": "GHSA-6p6j-f8q6-5r72",
  "modified": "2025-10-06T21:30:44Z",
  "published": "2025-06-09T15:31:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40669"
    },
    {
      "type": "WEB",
      "url": "https://www.incibe.es/en/incibe-cert/notices/aviso/multiple-vulnerabilities-tcman-gim-1"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-6P8F-P8J2-RQMV

Vulnerability from github – Published: 2026-08-06 16:40 – Updated: 2026-08-06 16:40
VLAI
Summary
Traefik: Gateway HTTPRoute backendRef filters can leak backend context across routes sharing a Service:port
Details

Summary

There is a medium severity vulnerability in Traefik's Kubernetes Gateway API provider. When two accepted HTTPRoutes target the same backend Service:port but configure different backendRef filters, Traefik may resolve both routes to the same child service and apply only one route's filter set to all requests reaching that backend. In Gateway deployments where backendRef filters set security-sensitive headers — such as tenant identity, authorization context, or values the backend trusts — an attacker who can create an accepted HTTPRoute sharing the same backend Service:port may cause their route's filter context to be applied to another route's requests, potentially crossing namespace boundaries when a ReferenceGrant permits cross-namespace targeting.

Patches

  • https://github.com/traefik/traefik/releases/tag/v3.7.6

For more information

If you have any questions or comments about this advisory, please open an issue.

Original Description # Traefik Gateway HTTPRoute backendRef filter context collision across routes sharing Service:port ## Summary Traefik's Kubernetes Gateway API provider builds the dynamic HTTP backend service key for a Gateway `HTTPRoute` backendRef from only the backend namespace, Service name, protocol, and port. It does not include the HTTPRoute, listener, rule, or backendRef filter identity in that key. When two accepted HTTPRoutes point to the same backend `Service:port` but define different backendRef filters, Traefik can make both route WRR services reference the same child service. The child service then carries only one backendRef filter set, so one route can send requests to the backend with another route's backend context. This is security-relevant when backendRef filters set, remove, or rewrite security-sensitive context, such as tenant, identity, auth, sanitization, Host, or path headers trusted by the backend. Credit: Qican Ma, Ding Luo @XiaoMi ShadowBlade Security Lab ## Suggested Severity Suggested severity: Medium/High, configuration-dependent. Suggested CVSS 3.1: 
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:H/A:N
Notes: - Requires Gateway API routes sharing the same backend Service:port with different security-sensitive backendRef filters trusted by the backend. - Cross-namespace impact is possible when route attachment and ReferenceGrant policy allow an attacker route to target the shared backend. - No RCE, memory corruption, or default-config exposure claimed. Suggested CWE: 
CWE-863: Incorrect Authorization
CWE-284: Improper Access Control
## Affected Component 
pkg/provider/kubernetes/gateway/httproute.go — loadService(), loadMiddlewares()
## Tested Versions Confirmed on: 
Traefik source snapshot: 29406d42898547f1ffabd904f66af06c212740cf on master
Earliest affected version not exhaustively determined. ## Root Cause `loadService` starts the dynamic service name from backend namespace and Service name only: 
// pkg/provider/kubernetes/gateway/httproute.go:245
serviceName := provider.Normalize(namespace + "-" + string(backendRef.Name) + "-http")
It loads backendRef filters using that same service name before appending the backend port: 
// pkg/provider/kubernetes/gateway/httproute.go:258
middlewares, err := p.loadMiddlewares(conf, namespace, serviceName, backendRef.Filters, pathMatch)
For normal Kubernetes Services, the final child service key appends only the port: 
// pkg/provider/kubernetes/gateway/httproute.go:304-317
portStr := strconv.FormatInt(int64(port), 10)
serviceName = provider.Normalize(serviceName + "-" + portStr)
...
conf.HTTP.Services[serviceName] = &dynamic.Service{LoadBalancer: lb, Middlewares: middlewares}
Each route/rule WRR service references the child service by name. Later route configs are merged by map key (`maps.Copy`), so both route-local WRR services can point to the same child service, which retains only one of the route/backendRef filter configurations. ## Attack Scenario 1. Gateway listener with `allowedRoutes.namespaces.from: All`. 2. Victim `HTTPRoute` `route-a` in namespace `default` targets `default/whoami:80` with backendRef filter setting `X-Tenant: tenant-a`. 3. Attacker-controlled `HTTPRoute` `route-b` in namespace `attacker` targets `default/whoami:80` (via ReferenceGrant) with backendRef filter setting `X-Tenant: tenant-b`. 4. Both routes generate the same child service key: `default-whoami-http-80`. 5. The second route's filter configuration overwrites the first (or vice versa) via `maps.Copy`. 6. Backend receives both routes' requests with one tenant's header context. ## Proof of Concept A Go test harness injects provider-level and server-level tests into the Traefik checkout. The provider test confirms the generated dynamic configuration collision. The server test builds Traefik's runtime router/service/middleware pipeline and sends `httptest` requests through router matching, WRR service dispatch, service-level backendRef middleware, and backend proxy capture. Observed result: 
{
  "name": "positive_cross_namespace_same_backend_filter_collision",
  "pass": true,
  "expected": {"route-a": "tenant-a", "route-b": "tenant-b"},
  "observed": {"route-a": "tenant-a", "route-b": "tenant-a"},
  "runtimeObserved": {"route-a": "tenant-a", "route-b": "tenant-a"},
  "childServices": {"route-a": "default-whoami-http-80", "route-b": "default-whoami-http-80"}
}
Negative controls confirmed: - Separate backend Service:port keys produce correct per-route filter isolation. - Identical filters across routes produce no security-relevant difference. The PoC files can be shared upon request. ## Impact An actor who can create or modify an accepted HTTPRoute can cause another accepted route that targets the same backend Service:port to use the wrong backendRef filter context. In cross-namespace Gateway deployments, this can cross namespace boundaries. High-value impact: gateway-injected tenant, identity, auth, role, header sanitization, Host rewrite, or path rewrite context is trusted by the backend. Lower-value impact: the overwritten header is informational or observability-only. ## Suggested Remediation 1. Include route/listener/rule/backendRef filter identity in the generated child service name when backendRef filters are present. 2. Split the load-balancer service from the backendRef filter application so per-route backend filters remain route-scoped. 3. Detect conflicting backendRef filters for the same generated service key and reject or disambiguate the configuration. ## Timeline 
2026-06-04: Discovered and reproduced with local test harness.
Severity
6.3 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:N/SC:L/SI:H/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.7.5"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/traefik/traefik/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.7.0"
            },
            {
              "fixed": "3.7.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54765"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-06T16:40:31Z",
    "nvd_published_at": "2026-07-06T21:16:57Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThere is a medium severity vulnerability in Traefik\u0027s Kubernetes Gateway API provider.\nWhen two accepted HTTPRoutes target the same backend Service:port but configure different\n`backendRef` filters, Traefik may resolve both routes to the same child service and apply\nonly one route\u0027s filter set to all requests reaching that backend. In Gateway deployments\nwhere `backendRef` filters set security-sensitive headers \u2014 such as tenant identity,\nauthorization context, or values the backend trusts \u2014 an attacker who can create an\naccepted HTTPRoute sharing the same backend Service:port may cause their route\u0027s filter\ncontext to be applied to another route\u0027s requests, potentially crossing namespace\nboundaries when a `ReferenceGrant` permits cross-namespace targeting.\n\n## Patches\n\n- https://github.com/traefik/traefik/releases/tag/v3.7.6\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# Traefik Gateway HTTPRoute backendRef filter context collision across routes sharing Service:port\n\n## Summary\n\nTraefik\u0027s Kubernetes Gateway API provider builds the dynamic HTTP backend service key for a Gateway `HTTPRoute` backendRef from only the backend namespace, Service name, protocol, and port. It does not include the HTTPRoute, listener, rule, or backendRef filter identity in that key.\n\nWhen two accepted HTTPRoutes point to the same backend `Service:port` but define different backendRef filters, Traefik can make both route WRR services reference the same child service. The child service then carries only one backendRef filter set, so one route can send requests to the backend with another route\u0027s backend context.\n\nThis is security-relevant when backendRef filters set, remove, or rewrite security-sensitive context, such as tenant, identity, auth, sanitization, Host, or path headers trusted by the backend.\n\nCredit: Qican Ma, Ding Luo @XiaoMi ShadowBlade Security Lab\n\n## Suggested Severity\n\nSuggested severity: Medium/High, configuration-dependent.\n\nSuggested CVSS 3.1:\n\n```text\nCVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:H/A:N\n```\n\nNotes:\n\n- Requires Gateway API routes sharing the same backend Service:port with different security-sensitive backendRef filters trusted by the backend.\n- Cross-namespace impact is possible when route attachment and ReferenceGrant policy allow an attacker route to target the shared backend.\n- No RCE, memory corruption, or default-config exposure claimed.\n\nSuggested CWE:\n\n```text\nCWE-863: Incorrect Authorization\nCWE-284: Improper Access Control\n```\n\n## Affected Component\n\n```text\npkg/provider/kubernetes/gateway/httproute.go \u2014 loadService(), loadMiddlewares()\n```\n\n## Tested Versions\n\nConfirmed on:\n\n```text\nTraefik source snapshot: 29406d42898547f1ffabd904f66af06c212740cf on master\n```\n\nEarliest affected version not exhaustively determined.\n\n## Root Cause\n\n`loadService` starts the dynamic service name from backend namespace and Service name only:\n\n```go\n// pkg/provider/kubernetes/gateway/httproute.go:245\nserviceName := provider.Normalize(namespace + \"-\" + string(backendRef.Name) + \"-http\")\n```\n\nIt loads backendRef filters using that same service name before appending the backend port:\n\n```go\n// pkg/provider/kubernetes/gateway/httproute.go:258\nmiddlewares, err := p.loadMiddlewares(conf, namespace, serviceName, backendRef.Filters, pathMatch)\n```\n\nFor normal Kubernetes Services, the final child service key appends only the port:\n\n```go\n// pkg/provider/kubernetes/gateway/httproute.go:304-317\nportStr := strconv.FormatInt(int64(port), 10)\nserviceName = provider.Normalize(serviceName + \"-\" + portStr)\n...\nconf.HTTP.Services[serviceName] = \u0026dynamic.Service{LoadBalancer: lb, Middlewares: middlewares}\n```\n\nEach route/rule WRR service references the child service by name. Later route configs are merged by map key (`maps.Copy`), so both route-local WRR services can point to the same child service, which retains only one of the route/backendRef filter configurations.\n\n## Attack Scenario\n\n1. Gateway listener with `allowedRoutes.namespaces.from: All`.\n2. Victim `HTTPRoute` `route-a` in namespace `default` targets `default/whoami:80` with backendRef filter setting `X-Tenant: tenant-a`.\n3. Attacker-controlled `HTTPRoute` `route-b` in namespace `attacker` targets `default/whoami:80` (via ReferenceGrant) with backendRef filter setting `X-Tenant: tenant-b`.\n4. Both routes generate the same child service key: `default-whoami-http-80`.\n5. The second route\u0027s filter configuration overwrites the first (or vice versa) via `maps.Copy`.\n6. Backend receives both routes\u0027 requests with one tenant\u0027s header context.\n\n## Proof of Concept\n\nA Go test harness injects provider-level and server-level tests into the Traefik checkout. The provider test confirms the generated dynamic configuration collision. The server test builds Traefik\u0027s runtime router/service/middleware pipeline and sends `httptest` requests through router matching, WRR service dispatch, service-level backendRef middleware, and backend proxy capture.\n\nObserved result:\n\n```json\n{\n  \"name\": \"positive_cross_namespace_same_backend_filter_collision\",\n  \"pass\": true,\n  \"expected\": {\"route-a\": \"tenant-a\", \"route-b\": \"tenant-b\"},\n  \"observed\": {\"route-a\": \"tenant-a\", \"route-b\": \"tenant-a\"},\n  \"runtimeObserved\": {\"route-a\": \"tenant-a\", \"route-b\": \"tenant-a\"},\n  \"childServices\": {\"route-a\": \"default-whoami-http-80\", \"route-b\": \"default-whoami-http-80\"}\n}\n```\n\nNegative controls confirmed:\n\n- Separate backend Service:port keys produce correct per-route filter isolation.\n- Identical filters across routes produce no security-relevant difference.\n\nThe PoC files can be shared upon request.\n\n## Impact\n\nAn actor who can create or modify an accepted HTTPRoute can cause another accepted route that targets the same backend Service:port to use the wrong backendRef filter context. In cross-namespace Gateway deployments, this can cross namespace boundaries.\n\nHigh-value impact: gateway-injected tenant, identity, auth, role, header sanitization, Host rewrite, or path rewrite context is trusted by the backend.\nLower-value impact: the overwritten header is informational or observability-only.\n\n## Suggested Remediation\n\n1. Include route/listener/rule/backendRef filter identity in the generated child service name when backendRef filters are present.\n2. Split the load-balancer service from the backendRef filter application so per-route backend filters remain route-scoped.\n3. Detect conflicting backendRef filters for the same generated service key and reject or disambiguate the configuration.\n\n## Timeline\n\n```text\n2026-06-04: Discovered and reproduced with local test harness.\n```\n\n\u003c/details\u003e\n\n---",
  "id": "GHSA-6p8f-p8j2-rqmv",
  "modified": "2026-08-06T16:40:31Z",
  "published": "2026-08-06T16:40:31Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/security/advisories/GHSA-6p8f-p8j2-rqmv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54765"
    },
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/pull/13367"
    },
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/commit/8aada7a7d52e4588a75386d8b86d270f6fe8d549"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/traefik/traefik"
    },
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/releases/tag/v3.7.6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:N/SC:L/SI:H/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Traefik: Gateway HTTPRoute backendRef filters can leak backend context across routes sharing a Service:port"
}
Mitigation
Architecture and Design
  • Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
  • Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Architecture and Design

Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Mitigation MIT-4.4
Architecture and Design

Strategy: Libraries or Frameworks

  • Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  • For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Mitigation
Architecture and Design
  • For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
  • One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
Mitigation
System Configuration Installation

Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list