CVE-2020-8554 Overview
CVE-2020-8554 is a man-in-the-middle vulnerability affecting all versions of Kubernetes. An attacker with the ability to create a ClusterIP service and set the spec.externalIPs field can intercept traffic destined for that IP address within the cluster. Additionally, an attacker who can patch the status of a LoadBalancer service (a privileged operation that should not typically be granted to users) can set status.loadBalancer.ingress.ip to achieve a similar traffic interception effect.
Critical Impact
Authenticated attackers can intercept cluster network traffic by manipulating Kubernetes service configurations, potentially compromising sensitive data in transit and enabling further lateral movement within the cluster.
Affected Products
- Kubernetes (all versions)
- Oracle Communications Cloud Native Core Network Slice Selection Function 1.2.1
- Oracle Communications Cloud Native Core Policy 1.15.0
- Oracle Communications Cloud Native Core Service Communication Proxy 1.14.0
Discovery Timeline
- 2021-01-21 - CVE-2020-8554 published to NVD
- 2024-11-21 - Last updated in NVD database
Technical Details for CVE-2020-8554
Vulnerability Analysis
This vulnerability represents a fundamental design issue in how Kubernetes handles service IP configurations. The Kubernetes API server fails to adequately restrict the ability of authenticated users to configure external IP addresses on ClusterIP services. When a user creates or modifies a service with arbitrary values in spec.externalIPs, the Kubernetes networking layer routes traffic destined for those IP addresses to the attacker-controlled service.
The attack is particularly dangerous because it can be executed by any user with permissions to create or modify services, which is a common permission in many Kubernetes deployments. The vulnerability enables man-in-the-middle attacks against any IP address that cluster nodes can route to, including external services and internal infrastructure components.
Root Cause
The root cause is classified under CWE-283 (Unverified Ownership). Kubernetes does not verify that a user or service legitimately owns or controls the external IP addresses they specify in service configurations. This lack of ownership verification allows any authenticated user with service creation privileges to claim arbitrary IP addresses, effectively hijacking network traffic.
The design assumes trusted users within the cluster, but this assumption fails in multi-tenant environments or when service accounts are compromised. There is no built-in validation to prevent users from specifying IP addresses belonging to critical infrastructure, external services, or other tenants.
Attack Vector
The attack is network-based and requires low-privilege access to the Kubernetes API. An attacker needs only the ability to create or modify Kubernetes services, which is often granted to application developers and service accounts. The attack flow involves:
- The attacker identifies a target IP address they wish to intercept traffic for
- The attacker creates a ClusterIP service with spec.externalIPs containing the target IP
- Kubernetes configures iptables/IPVS rules to route traffic for that IP to the malicious service
- Traffic from pods and nodes in the cluster destined for the target IP is redirected to the attacker's service
- The attacker can inspect, modify, or drop the intercepted traffic
For LoadBalancer services, the attacker requires the additional privilege to patch service status, which is typically a more restricted operation. However, if obtained, setting status.loadBalancer.ingress.ip achieves the same traffic interception capability.
Detection Methods for CVE-2020-8554
Indicators of Compromise
- Services created with spec.externalIPs pointing to internal infrastructure IPs or well-known external service IPs
- Unexpected modifications to LoadBalancer service status fields by non-cloud-controller service accounts
- Audit log entries showing service creation or modification with external IP specifications by unusual principals
- Network traffic anomalies where expected external destinations are resolving to cluster-internal endpoints
Detection Strategies
- Enable Kubernetes audit logging and monitor for CREATE/UPDATE operations on Service resources that include spec.externalIPs or status.loadBalancer.ingress modifications
- Deploy admission controllers (such as OPA Gatekeeper or Kyverno) with policies that alert on or block services with externalIPs configurations
- Implement network monitoring to detect traffic pattern changes where external IP traffic is unexpectedly routed internally
- Review RBAC configurations to identify principals with excessive service creation or status patching privileges
Monitoring Recommendations
- Configure SentinelOne Singularity Cloud Workload Protection to monitor Kubernetes API server activity for suspicious service configurations
- Set up alerts for any service creation containing spec.externalIPs in production namespaces
- Monitor kube-proxy and CNI plugin logs for unexpected iptables or IPVS rule changes
- Implement network segmentation monitoring to detect traffic flows that deviate from expected patterns
How to Mitigate CVE-2020-8554
Immediate Actions Required
- Audit all existing Kubernetes services for spec.externalIPs configurations and validate their legitimacy
- Implement admission controller policies to restrict or block the use of spec.externalIPs on services
- Review and tighten RBAC policies to limit service creation and status patching privileges to trusted principals
- Enable Kubernetes audit logging if not already configured to track service modifications
Patch Information
This vulnerability is a design limitation in Kubernetes rather than a traditional bug. As such, there is no direct patch that fixes the issue. Kubernetes has introduced the DenyServiceExternalIPs admission plugin in later versions, which can be enabled to block services from specifying external IPs. Additionally, Oracle has released patches for affected Oracle Communications Cloud Native Core products as documented in:
For detailed technical information, see the Kubernetes Security Announcement and GitHub Issue #97076.
Workarounds
- Enable the DenyServiceExternalIPs admission plugin by adding it to the API server --enable-admission-plugins flag
- Deploy OPA Gatekeeper or Kyverno policies to deny services with spec.externalIPs unless explicitly approved
- Use network policies to restrict egress traffic and limit the impact of potential traffic interception
- Consider using a service mesh with mutual TLS to protect traffic even if routing is manipulated
# Enable DenyServiceExternalIPs admission plugin
# Add to kube-apiserver command line arguments:
--enable-admission-plugins=DenyServiceExternalIPs,NodeRestriction,PodSecurityPolicy
# Example Kyverno ClusterPolicy to block externalIPs
# Save as deny-external-ips.yaml and apply with kubectl
# apiVersion: kyverno.io/v1
# kind: ClusterPolicy
# metadata:
# name: deny-external-ips
# spec:
# validationFailureAction: enforce
# rules:
# - name: deny-external-ips
# match:
# resources:
# kinds:
# - Service
# validate:
# message: "Services with spec.externalIPs are not allowed"
# pattern:
# spec:
# X(externalIPs): "null"
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
