Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
37 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
A half-blind Server Side Request Forgery (SSRF) vulnerability exists in kube-controller-manager when using the in-tree Portworx StorageClass. This vulnerability allows authorized users to leak arbitrary information from unprotected endpoints in the control plane’s host network (including link-local or loopback services).
Recommended action: Upgrade to 1.34.2, 1.33.6 or 1.32.10 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go k8s.io/kubernetes >= 1.32.0, <= 1.32.5; >= 1.33.0, <= 1.33.1
Fixed in
1.33.21.32.6· Vendor fix available
Issue
A vulnerability exists in the NodeRestriction admission controller where nodes can bypass dynamic resource allocation authorization checks. When the DynamicResourceAllocation feature gate is enabled, the controller properly validates resource claim statuses during pod status updates but fails to perform equivalent validation during pod creation. This allows a compromised node to create mirror pods that access unauthorized dynamic resources, potentially leading to privilege escalation.
Recommended action: Upgrade to 1.33.2 or 1.32.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A security vulnerability has been discovered in Kubernetes windows nodes that could allow a user with the ability to query a node's '/logs' endpoint to execute arbitrary commands on the host. This CVE affects only Windows worker nodes. Your worker node is vulnerable to this issue if it is running one of the affected versions listed below.
Recommended action: Upgrade to 1.32.1, 1.31.5, 1.30.9 or 1.29.13 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A security issue was discovered in Kubernetes where a large number of container checkpoint requests made to the unauthenticated kubelet read-only HTTP endpoint may cause a Node Denial of Service by filling the Node's disk.
Recommended action: Upgrade to 1.32.2, 1.31.6, 1.30.10 or 1.29.14 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Kubernetes kubelet component allows arbitrary command execution via specially crafted gitRepo volumes.This issue affects kubelet: through 1.28.11, from 1.29.0 through 1.29.6, from 1.30.0 through 1.30.2.
Recommended action: Upgrade to 1.30.3, 1.29.7 or 1.28.12 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A flaw was found in kube-controller-manager. This issue occurs when the initial application of a HPA config YAML lacking a .spec.behavior.scaleUp block causes a denial of service due to KCM pods going into restart churn.
Recommended action: Upgrade to 1.27.0-alpha.1 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A security issue was discovered in Kubernetes clusters with Windows nodes where BUILTIN\Users may be able to read container logs and NT AUTHORITY\Authenticated Users may be able to modify container logs.
Recommended action: Upgrade to 1.30.3, 1.29.7, 1.28.12 or 1.27.16 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Kubernetes kube-apiserver in versions v1.6-v1.15, and versions prior to v1.16.13, v1.17.9 and v1.18.7 are vulnerable to an unvalidated redirect on proxied upgrade requests that could allow an attacker to escalate privileges from a node compromise to a full cluster compromise.
Recommended action: Upgrade to 1.18.7, 1.17.9 or 1.16.13 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A security issue was discovered in Kubernetes where users may be able to launch containers that bypass the mountable secrets policy enforced by the ServiceAccount admission plugin when using containers, init containers, and ephemeral containers with the envFrom field populated. The policy ensures pods running with a service account may only reference secrets specified in the service account’s secrets field. Kubernetes clusters are only affected if the ServiceAccount admission plugin and the kubernetes.io/enforce-mountable-secrets annotation are used together with containers, init containers, and ephemeral containers with the envFrom field populated.
Recommended action: Upgrade to 1.29.4, 1.28.9 or 1.27.13 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A security issue was discovered in Kubernetes where a user that can create pods and persistent volumes on Windows nodes may be able to escalate to admin privileges on those nodes. Kubernetes clusters are only affected if they are using an in-tree storage plugin for Windows nodes.
Recommended action: Upgrade to 1.28.4, 1.27.8, 1.26.11 or 1.25.16 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
1.25.131.24.171.26.81.27.51.28.1· Vendor fix available
Issue
A security issue was discovered in Kubernetes where a user that can create pods on Windows nodes may be able to escalate to admin privileges on those nodes. Kubernetes clusters are only affected if they include Windows nodes.
Recommended action: Upgrade to 1.28.1, 1.27.5, 1.26.8 or 2 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
1.25.131.24.171.26.81.27.51.28.1· Vendor fix available
Issue
A security issue was discovered in Kubernetes where a user that can create pods on Windows nodes may be able to escalate to admin privileges on those nodes. Kubernetes clusters are only affected if they include Windows nodes.
Recommended action: Upgrade to 1.28.1, 1.27.5, 1.26.8 or 2 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Kube-proxy on Windows can unintentionally forward traffic to local processes listening on the same port (spec.ports[].port) as a LoadBalancer Service when the LoadBalancer controller does not set the status.loadBalancer.ingress[].ip field. Clusters where the LoadBalancer controller sets the status.loadBalancer.ingress[].ip field are unaffected.
Recommended action: Upgrade to 1.21.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Users may be able to launch containers that bypass the mountable secrets policy enforced by the ServiceAccount admission plugin when using ephemeral containers. The policy ensures pods running with a service account may only reference secrets specified in the service account’s secrets field. Kubernetes clusters are only affected if the ServiceAccount admission plugin and the kubernetes.io/enforce-mountable-secrets annotation are used together with ephemeral containers.
Recommended action: Upgrade to 1.27.3, 1.26.6, 1.25.11 or 1.24.15 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Users may be able to launch containers using images that are restricted by ImagePolicyWebhook when using ephemeral containers. Kubernetes clusters are only affected if the ImagePolicyWebhook admission plugin is used together with ephemeral containers.
Recommended action: Upgrade to 1.27.3, 1.26.6, 1.25.11 or 1.24.15 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A security issue was discovered in Kubelet that allows pods to bypass the seccomp profile enforcement. Pods that use localhost type for seccomp profile but specify an empty profile field, are affected by this issue. In this scenario, this vulnerability allows the pod to run in unconfined (seccomp disabled) mode. This bug affects Kubelet.
Recommended action: Upgrade to 1.27.2, 1.26.5, 1.25.10 or 1.24.14 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Kubernetes, if the logging level is set to at least 9, authorization and bearer tokens will be written to log files. This can occur both in API server logs and client tool output like kubectl. This affects <= v1.19.5, <= v1.18.13, <= v1.17.15, < v1.20.0-alpha2.
Recommended action: Upgrade to 1.20.0-alpha.2 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Kubernetes clusters using a logging level of at least 4, processing a malformed docker config file will result in the contents of the docker config file being leaked, which can include pull secrets or other registry credentials. This affects < v1.19.3, < v1.18.10, < v1.17.13.
Recommended action: Upgrade to 1.20.0-alpha.1 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Kubernetes client-go library logs request headers at verbosity levels of 7 or higher. This can disclose credentials to unauthorized users via logs or command output. Kubernetes components (such as kube-apiserver) prior to v1.16.0, which make use of basic or bearer token authentication, and run at high verbosity levels, are affected.
Recommended action: Upgrade to 1.16.0-beta.1 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go k8s.io/kubernetes >= 1.12.0, < 1.12.5; >= 1.13.0, < 1.13.1
Fixed in
1.12.51.13.1· Vendor fix available
Issue
In Kubernetes v1.12.0-v1.12.4 and v1.13.0, the rest.AnonymousClientConfig() method returns a copy of the provided config, with credentials removed (bearer token, username/password, and client certificate/key data). In the affected versions, rest.AnonymousClientConfig() did not effectively clear service account credentials loaded using rest.InClusterConfig()
Recommended action: Upgrade to 1.13.1 or 1.12.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Kubernetes versions 1.3.x, 1.4.x, 1.5.x, 1.6.x and prior to versions 1.7.14, 1.8.9 and 1.9.4 containers using a secret, configMap, projected or downwardAPI volume can trigger deletion of arbitrary files/directories from the nodes where they are running.
Recommended action: Upgrade to 1.9.4, 1.8.9 or 1.7.14 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Kubernetes versions 1.5.x, 1.6.x, 1.7.x, 1.8.x, and prior to version 1.9.6, the kubectl cp command insecurely handles tar data returned from the container, and can be caused to overwrite arbitrary local files.
Recommended action: Upgrade to 1.9.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In all Kubernetes versions prior to v1.11.8, v1.12.6, and v1.13.4, users that are authorized to make patch requests to the Kubernetes API Server can send a specially crafted patch of type "json-patch" (e.g. kubectl patch --type json or "Content-Type: application/json-patch+json") that consumes excessive resources while processing, causing a Denial of Service on the API Server.
Recommended action: Upgrade to 1.13.4, 1.12.6 or 1.11.8 by release line; some affected versions have no fix yet, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Kubernetes in OpenShift3 allows remote authenticated users to use the private images of other users should they know the name of said image.
Recommended action: Upgrade to 1.2.0-alpha.6 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A security issue was discovered in the Kubelet and kube-proxy components of Kubernetes which allows adjacent hosts to reach TCP and UDP services bound to 127.0.0.1 running on the node or in the node's network namespace. For example, if a cluster administrator runs a TCP service on a node that listens on 127.0.0.1:1234, because of this 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 bug.
Recommended action: Upgrade to 1.18.4, 1.17.7 or 1.16.11 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.