Alcide Rapid 7 Logo Alcide Rapid 7 Logo
Alcide has been acquired by Rapid7- a leading provider of security analytics and automation. Learn more

New Kubernetes Node Vulnerability (CVE-2020-8558) bypasses localhost boundary

July 9, 2020
Gadi Naor
Alcide's Co-Founder & CTO

ֿVulnerability Description and Impact

A security issue was discovered in kube-proxy which allows adjacent nodes/hosts to reach TCP and UDP services bound to running on the node or in the node’s network namespace (host network). This breaks security assumptions made by services listening on localhost.

This security bug was originally raised in issue #90259 which details how the kube-proxy sets net.ipv4.conf.all.route_localnet=1 and causes the system not to reject traffic to localhost which originates on other hosts (martian traffic). Such traffic would look like packets on the wire with an IPv4 destination in the range and a layer-2 destination MAC address of a target node may indicate that an attack is targeting this vulnerability.

Image: Kubernetes trust boundaries


For example, if a cluster administrator runs a TCP service on a node that listens on, because of this security bug, that service would be potentially reachable by other hosts on the same LAN as the node, or by containers running on the same node as the service. If the example service on port 1234 required no additional authentication (because it assumed that only other localhost processes could reach it), then it could be vulnerable to attacks that make use of this security bug.

While many Kubernetes installers explicitly disable the API Server’s insecure port, and Kubernetes v1.20 is planned to remove this insecure option, An API server that uses this insecure option and listens on will accept requests without authentication.
To mount such an attack on the API server, an attacker must have access to another system on the same LAN or with control of a container running on the master. Managed Kubernetes services such as EKS, AKS, GKE and others should be resilient attacks on the API server insecure port.


Are You Vulnerable?

The vulnerability affects kubelet & kube-proxy which are core Node components:

Affected Versions

  • kubelet/kube-proxy v1.18.0-1.18.3
  • kubelet/kube-proxy v1.17.0-1.17.6
  • kubelet/kube-proxy <=1.16.10

Or if one or more of the following items are applicable to your environments:

  1. Your cluster nodes run in an environment where untrusted hosts share the same layer 2 domain (i.e. same LAN) as the cluster nodes.
  2. Your cluster allows untrusted pods to run containers with CAP_NET_RAW which is enabled by default by Kubernetes.
  3. Your nodes (or hostnetwork pods) run any localhost-only services which do not require any further authentication. To list services that are potentially affected, run the following commands on nodes:
    – lsof +c 15 -P -n -i4TCP@ -sTCP:LISTEN
    – lsof +c 15 -P -n -i4UDP@



Automatic Detection of adjacent Node attacks with Alcide Runtime

This new vulnerability has long been covered by Alcide Runtime without requiring any configuration by the user. This detection has been part of Alcide Runtime for a long time, even prior to this vulnerability’s disclosure, and there was no need for us to add additional detection capabilities.


The traffic is flagged as spoofed traffic because localhost traffic should never cross network boundaries. Furthermore, if you explicitly define firewall policies using Alcide’s microservices firewall, then pods can’t access other resources in the network unless explicitly allowed. This is what zero trust networking is all about!

Automatic Detection of API Server attacks with Alcide kAudit


Exploit attempts of this vulnerability via the unsecured port of the API Server would show up in its audit log as entries from the “system:unsecured” principal, similar to entries from K8s services on the Master node accessing the API Server locally.

Alcide kAudit analyzes the audit log of the Kubernetes API Server, continuously updates and compares behavioral activity profiles to actual observed activity and automatically detects anomalous access patterns from cluster principals (in this case, “system:unsecured” account) to various resource types, k8s APIs, namespaces, and specific resources. Thus, Alcide kAudit can automatically alert security teams to suspected attacks that rely on CVE-2020-8558 as they occur.

Furthermore, Alcide kAudit users can configure and customize it to alert on audit entries violating their specific policy. They can, for example, add alerts on API Server activity that reads or modifies sensitive namespaces or resources in the cluster, and use such alerts if they happen as an indicator that an exploit may be in progress and should be investigated.


Automatic Detection of Vulnerable Clusters with Alcide Advisor

Alcide Advisor is a Kubernetes multi-cluster vulnerability scanner that covers rich Kubernetes and Istio security best practices and compliance checks such as Kubernetes vulnerability scanning, hunting misplaced secrets, or excessive secret access, and many more security configuration and compliance checks.

Image: Alcide Kubernetes Advisor


With Alcide Advisor users can:

  1. Identify the vulnerable clusters for this vulnerability (as well as other CVEs)
  2. Identify and explicitly allow/deny which Pods can run with elevated privileges that enables CAP_NET_RAW
  3. Identify and explicitly allow/deny which Pods can run on the host network.
  4. In applicable environments, Identify Pods that can run on master nodes that can potentially exploit the Kubernetes API Server.



Kubernetes, like any software, has bugs and vulnerabilities. Leveraging Kubernetes as cloud-native application infrastructure requires operators to monitor and secure all the moving parts, whether these are the application workloads or the platform and infrastructure components. CVE-2020-8558 joins other recent vulnerability disclosures CVE-2020-8555 and CVE-2020-10749 and highlights the need for a purpose built Kubernetes security solution that can drive cluster operators to run workloads, applications and infrastructure while leveraging the best security practices of the native kubernetes security controls, as well as security monitoring & prevention.

Start your 14 day trial or request a demo.

About the author

Gadi profile

Gadi Naor

Alcide's Co-Founder & CTO

Gadi Naor has 18 years of engineering experience, from kernel-based development through leading development of cybersecurity products starting his professional career at Check Point. Gadi then joined Altor Networks, a pioneer in virtualized data center security, later acquired by Juniper Networks. Prior to Alcide, Gadi co-founded Fitfully, at which he served as CTO. Gadi holds a B.A in Computer Science from the Technion Institute of Technology.

Subscribe for updates, fresh insights, stories and tips

The latest posts delivered to your inbox