CVE-2020-8561: Kubernetes Information Disclosure Flaw

CVE-2020-8561 Overview

A security issue was discovered in Kubernetes where actors that control the responses of MutatingWebhookConfiguration or ValidatingWebhookConfiguration requests are able to redirect kube-apiserver requests to private networks of the apiserver. If that user can view kube-apiserver logs when the log level is set to 10, they can view the redirected responses and headers in the logs.

This vulnerability represents a Server-Side Request Forgery (SSRF) condition within the Kubernetes API server that could allow privileged attackers to probe internal network services and potentially exfiltrate sensitive information through log file access.

Critical Impact

Attackers with webhook configuration privileges can redirect kube-apiserver requests to internal network services, potentially exposing sensitive data through API server logs when verbose logging is enabled.

Affected Products

• Kubernetes 1.20.11
• Kubernetes 1.21.5
• Kubernetes 1.22.2

Discovery Timeline

• September 20, 2021 - CVE CVE-2020-8561 published to NVD
• November 21, 2024 - Last updated in NVD database

Technical Details for CVE-2020-8561

Vulnerability Analysis

This vulnerability is classified under CWE-441 (Unintended Proxy or Intermediary) and CWE-610 (Externally Controlled Reference to a Resource in Another Sphere). The kube-apiserver component in Kubernetes fails to properly validate and restrict redirect responses from webhook configurations.

When an attacker controls a MutatingWebhookConfiguration or ValidatingWebhookConfiguration endpoint, they can craft responses that cause the API server to follow redirects to arbitrary internal network destinations. This effectively turns the kube-apiserver into an unintended proxy, allowing attackers to scan and interact with services on private networks that would otherwise be inaccessible.

The exploitation becomes particularly impactful when verbose logging (log level 10) is enabled, as the redirected responses and their headers are written to the API server logs. An attacker with log access can then extract the responses from internal services.

Root Cause

The root cause of this vulnerability lies in the insufficient validation of redirect responses from webhook endpoints. The kube-apiserver follows HTTP redirects from webhook responses without properly restricting the destination addresses. This allows webhook controllers to redirect requests to internal network addresses, including localhost services, cloud metadata endpoints, and other sensitive internal infrastructure.

The vulnerability is compounded by the fact that response data is logged when verbose logging is enabled, creating an information disclosure path for attackers who have both webhook configuration privileges and log access.

Attack Vector

The attack requires network access and high privileges within the Kubernetes cluster. An attacker must first gain the ability to create or modify MutatingWebhookConfiguration or ValidatingWebhookConfiguration resources. Once this access is obtained, the attacker can configure a webhook endpoint under their control to return redirect responses pointing to internal network services.

When the API server processes requests that trigger the webhook, it follows the redirect and makes requests to the attacker-specified internal addresses. The scope is changed (C in CVSS), meaning the vulnerable component impacts resources beyond its security scope. While the confidentiality impact is limited to low-sensitivity information disclosure, there is no direct integrity or availability impact from this vulnerability.

Detection Methods for CVE-2020-8561

Indicators of Compromise

• Unusual webhook configurations pointing to external or untrusted endpoints
• API server logs showing requests to internal IP addresses or metadata endpoints
• Webhook responses containing HTTP redirect status codes (301, 302, 307, 308)
• Unexpected network connections from the kube-apiserver to internal services

Detection Strategies

• Monitor and audit all MutatingWebhookConfiguration and ValidatingWebhookConfiguration resources for changes
• Implement network policies to restrict kube-apiserver egress traffic to known webhook endpoints
• Review API server logs for evidence of redirect following to internal addresses
• Alert on webhook configurations created by non-administrative users

Monitoring Recommendations

• Enable audit logging for webhook configuration resources with detailed request/response capture
• Monitor kube-apiserver network connections for unexpected destination addresses
• Set up alerts for API server log verbosity changes, particularly increases to level 10
• Implement continuous monitoring of webhook endpoint health and response patterns

How to Mitigate CVE-2020-8561

Immediate Actions Required

• Restrict permissions for creating or modifying webhook configurations to trusted administrators only
• Review and audit all existing MutatingWebhookConfiguration and ValidatingWebhookConfiguration resources
• Ensure API server log level is not set to 10 in production environments
• Implement network policies to limit kube-apiserver outbound connections

Patch Information

Kubernetes has addressed this vulnerability through updated guidance and configuration options. Organizations should review the Kubernetes Security Issue #104720 and the Kubernetes Security Announcement for specific remediation steps.

Additional vendor-specific guidance is available from NetApp Security Advisory.

Workarounds

• Apply strict RBAC policies to limit webhook configuration capabilities to cluster administrators
• Use network policies or firewall rules to prevent the API server from reaching internal metadata services
• Avoid setting API server log verbosity to level 10 in production environments
• Consider implementing a webhook admission policy that restricts allowed webhook endpoint addresses

# Example: Restrict webhook configuration permissions via RBAC
# Create a ClusterRole that denies webhook configuration access to non-admins
kubectl create clusterrole deny-webhook-config \
  --verb=create,update,patch,delete \
  --resource=mutatingwebhookconfigurations,validatingwebhookconfigurations

# Audit existing webhook configurations
kubectl get mutatingwebhookconfigurations -o yaml
kubectl get validatingwebhookconfigurations -o yaml

# Check current API server log level (in kube-apiserver manifest)
grep -i "v=" /etc/kubernetes/manifests/kube-apiserver.yaml