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
Why all businesses must democratise data analytics
How start-ups can take the next step towards scaling up
Unlocking the value of artificial intelligence and machine learning

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
NEWSLETTER Sign up Tick the boxes of the newsletters you would like to receive. 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.
I consent to New Statesman Media Group collecting my details provided via this form in accordance with the Privacy Policy