The confused deputy lives in your cluster: externalIPs, webhook redirects, and traffic you did not authorize

The confused-deputy problem is one of the oldest in security: a privileged component is tricked by a less-privileged actor into misusing its authority. Kubernetes, by design, is full of privileged deputies (the API server, admission controllers, the service proxy) that act on behalf of users across the whole cluster. Three CVEs that resurface in current intelligence feeds are worth studying together because they are not really three bugs; they are three faces of one structural truth: in a multi-tenant cluster, the control plane's reach is an attack surface, and you must constrain who can borrow it.

CVE-2020-8554: the externalIPs man-in-the-middle

The most impactful of the three. The Kubernetes API server, in all versions, lets a user who can create a ClusterIP Service set the spec.externalIPs field, and traffic to that external IP gets intercepted by the Service. A user with permission to create Services can therefore claim an external IP they do not own and intercept traffic destined for it: a man-in-the-middle from inside the cluster, with no special privilege beyond “can create a Service.” The related variant lets an actor who can patch a LoadBalancer Service's status set status.loadBalancer.ingress.ip to similar effect.

Crucially, there is no version you can upgrade to that simply removes this. externalIPs is a legitimate feature; the issue is that there is no built-in restriction on who can use it. The mitigation is an admission policy (historically a webhook, today a built-in ValidatingAdmissionPolicy or policy engine) that restricts or forbids externalIPs usage. The fix is something you configure, not something you install.

CVE-2020-8561: the webhook that redirects into your private network

The second issue lives in admission webhooks. An actor who controls the responses of a MutatingWebhookConfiguration or ValidatingWebhookConfiguration can redirect kube-apiserver requests to private networks of the API server: a server-side request forgery using the API server as the confused deputy. The API server, doing exactly what the webhook told it, reaches into networks the webhook's author could not reach directly. (Disclosure of the redirected response is gated on a very high log verbosity, which narrows the read primitive but not the redirect itself.)

The lesson is about who you let configure a webhook. An admission webhook is a piece of code the API server trusts implicitly on every relevant request. Permission to create or modify webhook configurations is therefore a powerful grant: it should be tightly held, and webhook endpoints should be constrained to known, internal, non-redirectable targets.

CVE-2021-25740: Endpoint/EndpointSlice confused deputy

The third rounds out the theme: a security issue where users could send network traffic to locations they would otherwise not have access to, via a confused-deputy attack involving Endpoints and EndpointSlices. Once again, the mechanism is a user steering the cluster's networking to reach a destination their own permissions would not allow, and once again, the resolution is mitigation guidance (restrict who can create Endpoints/EndpointSlices pointing at sensitive addresses) rather than a clean patch.

The common defense: constrain the deputy

Because all three are design issues, the defense is consistent and it is yours to configure:

• Restrict externalIPs. Deploy an admission policy that forbids or tightly allowlists spec.externalIPs on Services. This is the canonical CVE-2020-8554 mitigation and it is non-optional in any multi-tenant cluster.
• Lock down webhook configuration rights. Treat permission to create/modify admission webhooks as highly privileged. Constrain webhook targets to known internal services; do not let them point at arbitrary or redirectable URLs.
• Restrict Endpoint/EndpointSlice creation so low-privilege tenants cannot register endpoints pointing at sensitive internal addresses.
• Default-deny network policy. A cluster-wide default-deny posture limits where intercepted or redirected traffic can actually go, blunting all three even where a deputy is briefly confused.

The audit is read-only: confirm the mitigations exist, rather than attempting the interception:

# Confused-deputy mitigations present? (read-only posture audit)
# 1) Is externalIPs restricted by admission policy?
kubectl get validatingadmissionpolicy,validatingwebhookconfiguration 2>/dev/null \
  | grep -i 'externalip\|service'
# 2) Who can create Services / webhooks / Endpoints (the deputy-borrowing rights)?
kubectl auth can-i create services --as=system:serviceaccount:tenant-a:default
kubectl auth can-i create validatingwebhookconfigurations --as=system:serviceaccount:tenant-a:default
kubectl auth can-i create endpointslices --as=system:serviceaccount:tenant-a:default
# 3) Default-deny network policy in tenant namespaces?
kubectl get networkpolicy -A | grep -i 'default-deny'
# FINDING = a tenant can set externalIPs / configure webhooks / create endpoints
# with no admission backstop and no default-deny. Mitigations present = PASS.

Why old CVEs still matter

It would be easy to dismiss 2020-era CVEs as solved history. They are not, precisely because they have no clean patch: a freshly built cluster in 2026 is exposed to all three unless someone configured the mitigations. They keep surfacing in intelligence feeds for the same reason: they describe permanent properties of how Kubernetes routes traffic, and every new multi-tenant cluster re-inherits them. The control plane's reach is a feature; whether it is also a vulnerability is decided entirely by your RBAC and admission policy.

How Celvex Sentry tests for this

Our continuous-monitoring suite audits clusters for the confused-deputy mitigations directly: whether externalIPs is restricted, whether webhook-configuration and Endpoint creation rights are tightly held, and whether default-deny network policy is in place. Because these are design issues, the finding is the absence of the mitigation for a reachable tenant: we confirm it read-only, never by performing the interception. When a tenant can borrow the control plane's reach with no backstop, we mint a Proof Capsule with the can-i evidence and the admission-policy remediation attached. When the mitigations are present, we record a PASS.