A security issue was discovered in kube-state-metrics 1.7.x before 1.7.2. An experimental feature was added to v1.7.0 and v1.7.1 that enabled annotations to be exposed as metrics. By default, kube-state-metrics metrics only expose metadata about Secrets. However, a combination of the default kubectl behavior and this new feature can cause the entire secret content to end up in metric labels, thus inadvertently exposing the secret content in metrics.
Denial of service vulnerability in the kube-apiserver, allowing authorized users sending malicious YAML or JSON payloads to cause kube-apiserver to consume excessive CPU or memory, potentially crashing and becoming unavailable. Prior to v1.14.0, default RBAC policy authorized anonymous users to submit requests that could trigger this vulnerability.
net/http and golang.org/x/net/http2 servers that accept direct connections from untrusted clients could be remotely made to allocate an unlimited amount of memory, until the program crashes. Servers will now close connections if the send queue accumulates too many control messages.
An experimental feature was added to the v1.7.0 release that enabled annotations to be exposed as metrics. By default, the kube-state-metrics metrics only expose metadata about Secrets. However, a combination of the default `kubectl` behavior and this new feature can cause the entire secret content to end up in metric labels thus inadvertently exposing the secret content in metrics.
The debugging endpoint /debug/pprof is exposed over the unauthenticated Kubelet healthz port. The issue is of medium severity, but only exposed locally by the default configuration.
This vulnerability allows a malicious container to cause a file to be created or replaced on the client computer when the client uses the kubectl cp operation. The vulnerability is a client-side defect and requires user interaction to be exploited.
This vulnerability allows access to a cluster-scoped custom resource if the request is made as if the resource were namespaced. Authorizations for the resource accessed in this manner are enforced using roles and role bindings within the namespace, meaning that a user with access only to a resource in one namespace could create, view update or delete the cluster-scoped resource (according to their namespace role privileges).
Another security issue was discovered with the Kubernetes kubectl cp command that could enable a directory traversal such that a malicious container could replace or create files on a user’s workstation. The vulnerability is a client-side defect and requires user interaction to be exploited. The issue is High severity and upgrading kubectl to Kubernetes 1.12.9, 1.13.6, and 1.14.2 or later is encouraged to fix this issue.