Threat Response: Kubernetes – Privilege Escalation (CVE-2018-1002105)


Yesterday evening, a vulnerability regarding Kubernetes, a popular open-source container-orchestration service, was disclosed [1, 2]. We would like to inform you about the risks involved and the possible mitigations. The vulnerability obtained the ID CVE-2018-1002105, with a CVSS score of 9.8. If you are using Kubernetes, or any cloud service based on Kuberneters, we advise you to read this message carefully and to perform the mitigations mentioned in this message as soon as possible.


Kubernetes is a tool that enables users to easily host applications in the cloud by the use of containers. A typical setup consists of a collection of containers and so-called “pods”, which can contain multiple containers. Managing the containers and pods can be done using the Kubernetes API, which can also be made accessible remotely. In most cases, a “pod” runs on a single host, with the containers sharing the resources (memory, processor, storage, etc.) of the host machine.

Different cloud services make use of Kubernetes, such as:

  • Google GKE [3]
  • Microsoft AKS [4]
  • RedHat OpenShift [5]
  • Amazon EKS

The vulnerability exists in the Kubernetes API server, handling the API calls. Affected versions are:

  • Kubernetes v1.0.x-1.9.x
  • Kubernetes v1.10.0-1.10.10
  • Kubernetes v1.11.0-1.11.4
  • Kubernetes v1.12.0-1.12.2


The vulnerability will give full access to the API to unauthenticated users. Random commands can then be run against the “pods” (containers). In the standard configuration, anonymous access to the Kubernetes API is permitted to facilitate service discovery. Even when anonymous access is turned off, an unauthenticated user with common permissions, like in the “view” role, may be able to exploit the vulnerability and acquire full access.

In summary, this means that in nearly all common configurations for Kubernetes, a user that is able to connect to the Kubernetes API can get full access.

There is no existing way to detect the exploit in the Kubernetes logs, because the malicious API calls are not distinguishable from the normal API calls. Combined with the ease of access, we assess the risk of this exploit to be very high.


Currently, no other mitigation than turning off SMT on the vulnerable machines.

What will Northwave do?

The only mitigation that fully fixes the vulnerability is by updating Kubernetes to a patched version. These versions are:

If you are using a cloud service based on Kubernetes, we recommend you to contact the cloud service about the current status regarding this vulnerability, and the current used version of Kubernetes.

There exist some mitigations on vulnerable versions of Kubernetes, but these will hamper the functionality. Therefore, we do not recommend to perform any of these migitations. (See [1] and [5] for more information regarding the possible mitigations on vulnerable versions).

If you need additional information you can call us by phone or send us an email.

E-mail: [email protected]
Do you have an incident right now? Call our CERT number: +31 (0)85-0437 909 or 0800-1744 (alleen vanuit Nederland)







Northwave has made every effort to make this information accurate and reliable. However, the information provided is without warranty of any kind and its use is at the sole risk of the user. Northwave does not accept any responsibility or liability for the accuracy, content, completeness, legality or reliability of the information provided. We shall not be liable for any loss or damage of whatever nature, direct or indirect, consequential or other, whether arising in contract, tort or otherwise, which may arise as a result of your use of, or inability to use, this information or any additional information provided by us in direct or indirect relation to the information provided here.