Loading vulnerability…
Admission Webhook Redirect SSRF in Kubernetes kube-apiserver
CVE-2020-8561 is a server-side request forgery vulnerability in Kubernetes kube-apiserver admission webhook handling. The API server follows HTTP redirects received when invoking mutating or validating admission webhooks, allowing an actor controlling webhook responses to redirect requests to private networks reachable from the control plane. If kube-apiserver logging verbosity is set to 10 and the attacker can read its logs, redirected response bodies and headers can be disclosed. Profiling functionality can allow a sufficiently privileged attacker to raise logging verbosity dynamically. The issue remains unfixed across Kubernetes versions because restricting redirect behavior would disrupt legitimate integrations.
What it means and what to do now: patch path, interim mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
An attacker can cross network trust boundaries by inducing requests from the API server to internal services that are otherwise inaccessible to the attacker. Without access to verbose logs, exploitation can reveal limited connectivity or port-reachability information. With access to API server logs at verbosity 10, the attacker can obtain redirected response bodies and headers, potentially exposing sensitive internal information. Risk is greatest where the control plane occupies a more privileged network zone than tenant workloads, particularly in managed Kubernetes environments.
If you can’t patch tonight, do this now.
Set kube-apiserver logging verbosity below 10 and disable profiling with --profiling=false to prevent dynamic increases in logging verbosity. Restrict API server network access to sensitive resources so redirected webhook requests cannot reach privileged services. Limit admission webhook configuration privileges to trusted administrators and restrict access to API server logs and debugging functionality.
Patch, then assume compromise.
No Kubernetes code fix is currently available. Upgrading Kubernetes alone does not remediate this architectural issue; apply configuration and network mitigations.
No public exploits tracked yet. Mallory keeps watching.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
17 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.