Gardener CVE-2026-79767

Requires an authenticated actor holding the project-administrator role on a Gardener Project who has NOT been granted the manage-members permission (the exact separation-of-duties this plugin is meant to enforce). The actor must be able to submit an update to Project.spec.members via the Gardener API adding a Group or ServiceAccount subject (e.g. system:authenticated) - the flaw is that the customverbauthorizer admission plugin's mustCheckProjectMembers/findHumanUsersWithRoles logic only diffs User subjects and ignores Group and ServiceAccount changes. Limiting factors: exploitation is confined to Gardener versions prior to 1.142.6 / 1.143.3 / 1.144.2 / 1.145.0, requires pre-existing project-admin standing (no anonymous or low-privilege path), and is scoped to the attacker's own project rather than the whole landscape.

This is a genuine but privilege-gated authorization flaw (CWE-863), not a critical remote break. The CVSS vector CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:H/A:N correctly reflects that exploitation is trivial once the precondition is met (AC:L, UI:N) but requires elevated standing - PR:H - because the actor must already be a project administrator on a Gardener Project. No EPSS score, no CISA KEV listing, and no public exploit code are present in the provided data, so exploitation status is: no public exploit identified at time of analysis. No SSVC decision record was supplied. There is no signal conflict on exploitability, but there is a signal tension on impact: the vendor scored confidentiality as C:L, yet the description states the resulting access 'can include Shoots, Secrets, and cloud provider credentials,' which reads closer to C:H - verify impact scoping with the Gardener advisory. Net: this is a legitimate least-privilege/segregation-of-duties defect that matters to Gardener operators and their tenants, but it is a lateral privilege-escalation issue requiring an existing malicious or compromised project admin, not an internet-facing pre-auth threat, so it belongs in routine patch cycles rather than emergency response for most environments.

A user who holds the project-administrator role but was deliberately denied the manage-members permission edits Project.spec.members and adds a Group subject such as system:authenticated (or an arbitrary ServiceAccount) with a broad role. Because the customverbauthorizer admission plugin only diffs User subjects and ignores Group/ServiceAccount changes, the addition is accepted, silently granting wide project access - including to Shoots, Secrets, and cloud provider credentials. No public proof-of-concept is available, but the code fix and test changes in PR #15080 concretely confirm the mechanism.