CVE-2026-40815: Kubernetes admission-webhook bypass hands over cluster-admin

CVE-2026-40815 is a logic bug in how kube-apiserver resolves mutating admission webhooks. A user with permission to create a single MutatingWebhookConfiguration — permissions often granted to service-operators with "no cluster-admin" — can register a webhook whose rules intercept requests destined for privileged resources, then forge admission responses that instruct the API server to apply attacker-controlled patches. The net result: any user who can create webhooks can achieve cluster-admin within a single API request.

Why this bypasses RBAC

Kubernetes RBAC gates who can perform a request, not what the admission pipeline does with it. The admission chain was designed to validate and optionally mutate incoming objects — not to authorize changes on other objects. The vulnerable code path lets a crafted webhook response inject a patches block that the API server applies after RBAC evaluation, meaning the original caller's permissions are irrelevant. The attacker-created webhook effectively runs as the API server.

The canonical exploit chain is:

• Low-privilege user creates a MutatingWebhookConfiguration matching rbac.authorization.k8s.io/v1 resources.
• Any cluster event (including ones the user cannot normally see) triggers the webhook.
• Webhook responds with a patch that creates a ClusterRoleBinding granting the attacker cluster-admin.
• RBAC never sees the patch as an independent request — it's merged server-side as part of the original request's admission.

Any permission that includes mutatingwebhookconfigurations/create was effectively "cluster-admin waiting for the right trigger" on affected versions. Audit for it.

Who is exposed

• Multi-tenant clusters where operators get fine-grained namespace permissions plus webhook management — common in platform-engineering setups.
• Managed Kubernetes (EKS, GKE, AKS) running affected minor versions — patched controlplanes roll out over days, not all at once.
• GitOps workflows that sync webhook configurations from a Git repo — a compromised PR can register the attacker's webhook on merge.
• CI/CD pipelines that have RBAC to deploy admission controllers for testing.

Mitigation

Upgrade to the patched minor: 1.29.14, 1.30.10, or 1.31.6. The patch adds a post-admission RBAC re-check on any patch that touches protected resources (clusterroles, clusterrolebindings, nodes, secrets, serviceaccounts).

If you can't upgrade immediately:

• Remove mutatingwebhookconfigurations/create from any role that isn't genuinely cluster-admin. If a user needs to deploy a webhook for testing, gate it through a controller that validates.
• Audit existing MutatingWebhookConfiguration objects for suspicious rules matching RBAC resources or secrets.
• Enable audit logging at RequestResponse level for admissionregistration.k8s.io — catches post-compromise webhook creation.
• Falco rule (available in the artifact folder): alert on creation of webhooks whose rules[*].resources includes clusterroles or clusterrolebindings.

The broader pattern

This is the third Kubernetes CVE in five years where admission-stage logic was abused to subvert the authorization layer that runs before it — CVE-2022-3172 (KubeletPodName), CVE-2024-7646 (Ingress-NGINX annotation), now CVE-2026-40815. The recurring root cause: admission controllers run with the API server's privilege, not the caller's, and their output is trusted. If you run admission webhooks at all, assume every new CVE in this space could be another cluster-admin primitive.