View all newsletters
Receive our newsletter - data, insights and analysis delivered to you
  1. Technology
  2. Cybersecurity
June 1, 2020updated 02 Jun 2020 11:56am

Kubernetes Clusters Vulnerable to Man-in-the-Middle Attacks

"Setting the host default to reject router advertisements should prevent attacks from succeeding but may break legitimate traffic"

By CBR Staff Writer

Kubernetes clusters configured to use certain container networking
implementations (CNIs) are susceptible to man-in-the-middle (MitM) attacks, the Kubernetes Product Security Committee has warned.

The vulnerability affects clusters running a “default Kubernetes security context”: i.e. workloads running with CAP_NET_RAW privileges.

There’s no upstream fix till June 17, so users may want to mitigate or take some manual steps to individually update the CNI plugins that are the culprit — these have found their way into upstream kubelet binary releases.

What’s this Kubernetes Bug Do?

The container networking vulnerability can be exploited by sending rogue router advertisements: this lets a malicious container reconfigure the host to redirect its IPv6 traffic to an attacker-controlled container.


(n.b. “Even if there was no IPv6 traffic before, if the DNS returns A (IPv4) and AAAA (IPv6) records, many HTTP libraries will try to connect via IPv6 first then fallback to IPv4, giving an opportunity to the attacker to respond.”)

Where’s the Bug?

The bug is not in Kubernetes per se, but in various CNI plugins.

Content from our partners
Scan and deliver
GenAI cybersecurity: "A super-human analyst, with a brain the size of a planet."
Cloud, AI, and cyber security – highlights from DTX Manchester

These have been bundled into various upstream binary kubelet (the lowest level component in Kubernetes) releases, including those installed from upstream Kubernetes community repositories hosted at

See also: 7 of the World’s Top 10 Open Source Packages Come with This Warning

The following official kubelet package versions have a kubernetes-cni package as a dependency that is affected by the vulnerability.

* kubelet v1.18.0-v1.18.3
* kubelet v1.17.0-v1.17.6
* kubelet < v1.16.11

Affected container networking implementations include:

* CNI Plugins maintained by the container networking team
<>, prior to version
0.8.6 (CVE-2020-10749)
* Calico and Calico Enterprise (CVE-2020-13597)  Please refer to the
Tigera Advisory TTA-2020-001 at for details
* Docker versions prior to 19.03.11 (see (CVE-2020-13401)
* Weave Net, prior to version 2.6.3

The vulnerability has a “medium” CVSS score of 6.0, but probably shouldn’t be ignored, considering what can be done with it.

The Kubernetes Product Security Committee suggests the following mitigations: “Setting the host default to reject router advertisements should
prevent attacks from succeeding…”

This “may break legitimate traffic, depending upon the networking implementation and the network where the cluster is running. To change this setting, set the sysctlnet.ipv6.conf.all.accept_ra to 0.”

It also suggests using TLS with proper certificate validation and disallowing CAP_NET_RAW for untrusted workloads or users.

Credit for the find goes to Etienne Champetier.

A more detail analysis of the issue including detection details is here.

See also: What the Hell is Kubernetes?

Websites in our network
Select and enter your corporate email address Tech Monitor's research, insight and analysis examines the frontiers of digital transformation to help tech leaders navigate the future. Our Changelog newsletter delivers our best work to your inbox every week.
  • CIO
  • CTO
  • CISO
  • CSO
  • CFO
  • CDO
  • CEO
  • Architect Founder
  • MD
  • Director
  • Manager
  • Other
Visit our privacy policy for more information about our services, how Progressive Media Investments may use, process and share your personal data, including information on your rights in respect of your personal data and how you can unsubscribe from future marketing communications. Our services are intended for corporate subscribers and you warrant that the email address submitted is your corporate email address.