Filtered by vendor Kubernetes
Subscriptions
Total
107 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-5154 | 2 Kubernetes, Redhat | 4 Cri-o, Enterprise Linux, Openshift and 1 more | 2025-07-24 | 8.1 High |
| A flaw was found in cri-o. A malicious container can create a symbolic link to arbitrary files on the host via directory traversal (“../“). This flaw allows the container to read and write to arbitrary files on the host system. | ||||
| CVE-2025-1974 | 1 Kubernetes | 1 Ingress-nginx | 2025-07-21 | 9.8 Critical |
| A security issue was discovered in Kubernetes where under certain conditions, an unauthenticated attacker with access to the pod network can achieve arbitrary code execution in the context of the ingress-nginx controller. This can lead to disclosure of Secrets accessible to the controller. (Note that in the default installation, the controller can access all Secrets cluster-wide.) | ||||
| CVE-2024-45310 | 4 Docker, Kubernetes, Linux and 1 more | 4 Docker, Kubernetes, Linux Kernel and 1 more | 2025-07-12 | 3.6 Low |
| runc is a CLI tool for spawning and running containers according to the OCI specification. runc 1.1.13 and earlier, as well as 1.2.0-rc2 and earlier, can be tricked into creating empty files or directories in arbitrary locations in the host filesystem by sharing a volume between two containers and exploiting a race with `os.MkdirAll`. While this could be used to create empty files, existing files would not be truncated. An attacker must have the ability to start containers using some kind of custom volume configuration. Containers using user namespaces are still affected, but the scope of places an attacker can create inodes can be significantly reduced. Sufficiently strict LSM policies (SELinux/Apparmor) can also in principle block this attack -- we suspect the industry standard SELinux policy may restrict this attack's scope but the exact scope of protection hasn't been analysed. This is exploitable using runc directly as well as through Docker and Kubernetes. The issue is fixed in runc v1.1.14 and v1.2.0-rc3. Some workarounds are available. Using user namespaces restricts this attack fairly significantly such that the attacker can only create inodes in directories that the remapped root user/group has write access to. Unless the root user is remapped to an actual user on the host (such as with rootless containers that don't use `/etc/sub[ug]id`), this in practice means that an attacker would only be able to create inodes in world-writable directories. A strict enough SELinux or AppArmor policy could in principle also restrict the scope if a specific label is applied to the runc runtime, though neither the extent to which the standard existing policies block this attack nor what exact policies are needed to sufficiently restrict this attack have been thoroughly tested. | ||||
| CVE-2025-1097 | 1 Kubernetes | 1 Ingress-nginx | 2025-07-12 | 8.8 High |
| A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-tls-match-cn` Ingress annotation can be used to inject configuration into nginx. This can lead to arbitrary code execution in the context of the ingress-nginx controller, and disclosure of Secrets accessible to the controller. (Note that in the default installation, the controller can access all Secrets cluster-wide.) | ||||
| CVE-2025-1098 | 1 Kubernetes | 1 Ingress-nginx | 2025-07-12 | 8.8 High |
| A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `mirror-target` and `mirror-host` Ingress annotations can be used to inject arbitrary configuration into nginx. This can lead to arbitrary code execution in the context of the ingress-nginx controller, and disclosure of Secrets accessible to the controller. (Note that in the default installation, the controller can access all Secrets cluster-wide.) | ||||
| CVE-2025-24514 | 1 Kubernetes | 1 Ingress-nginx | 2025-07-12 | 8.8 High |
| A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-url` Ingress annotation can be used to inject configuration into nginx. This can lead to arbitrary code execution in the context of the ingress-nginx controller, and disclosure of Secrets accessible to the controller. (Note that in the default installation, the controller can access all Secrets cluster-wide.) | ||||
| CVE-2025-4563 | 1 Kubernetes | 1 Kubernetes | 2025-06-27 | 2.7 Low |
| 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. | ||||
| CVE-2021-25736 | 3 Kubernetes, Microsoft, Redhat | 3 Kubernetes, Windows, Openshift | 2025-06-12 | 5.8 Medium |
| 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. | ||||
| CVE-2023-5044 | 1 Kubernetes | 1 Ingress-nginx | 2025-06-12 | 7.6 High |
| Code injection via nginx.ingress.kubernetes.io/permanent-redirect annotation. | ||||
| CVE-2022-2995 | 2 Kubernetes, Redhat | 2 Cri-o, Openshift | 2025-05-29 | 7.1 High |
| Incorrect handling of the supplementary groups in the CRI-O container engine might lead to sensitive information disclosure or possible data modification if an attacker has direct access to the affected container where supplementary groups are used to set access permissions and is able to execute a binary code in that container. | ||||
| CVE-2017-1000056 | 1 Kubernetes | 1 Kubernetes | 2025-04-20 | N/A |
| Kubernetes version 1.5.0-1.5.4 is vulnerable to a privilege escalation in the PodSecurityPolicy admission plugin resulting in the ability to make use of any existing PodSecurityPolicy object. | ||||
| CVE-2017-1002100 | 1 Kubernetes | 1 Kubernetes | 2025-04-20 | N/A |
| Default access permissions for Persistent Volumes (PVs) created by the Kubernetes Azure cloud provider in versions 1.6.0 to 1.6.5 are set to "container" which exposes a URI that can be accessed without authentication on the public internet. Access to the URI string requires privileged access to the Kubernetes cluster or authenticated access to the Azure portal. | ||||
| CVE-2015-7561 | 2 Kubernetes, Redhat | 2 Kubernetes, Openshift | 2025-04-20 | N/A |
| Kubernetes in OpenShift3 allows remote authenticated users to use the private images of other users should they know the name of said image. | ||||
| CVE-2016-1905 | 2 Kubernetes, Redhat | 2 Kubernetes, Openshift | 2025-04-12 | N/A |
| The API server in Kubernetes does not properly check admission control, which allows remote authenticated users to access additional resources via a crafted patched object. | ||||
| CVE-2016-1906 | 2 Kubernetes, Redhat | 2 Kubernetes, Openshift | 2025-04-12 | N/A |
| Openshift allows remote attackers to gain privileges by updating a build configuration that was created with an allowed type to a type that is not allowed. | ||||
| CVE-2015-7528 | 2 Kubernetes, Redhat | 2 Kubernetes, Openshift | 2025-04-12 | N/A |
| Kubernetes before 1.2.0-alpha.5 allows remote attackers to read arbitrary pod logs via a container name. | ||||
| CVE-2025-24513 | 1 Kubernetes | 1 Ingress-nginx | 2025-03-27 | 4.8 Medium |
| A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where attacker-provided data are included in a filename by the ingress-nginx Admission Controller feature, resulting in directory traversal within the container. This could result in denial of service, or when combined with other vulnerabilities, limited disclosure of Secret objects from the cluster. | ||||
| CVE-2024-7598 | 1 Kubernetes | 1 Kubernetes | 2025-03-20 | 3.1 Low |
| A security issue was discovered in Kubernetes where a malicious or compromised pod could bypass network restrictions enforced by network policies during namespace deletion. The order in which objects are deleted during namespace termination is not defined, and it is possible for network policies to be deleted before the pods that they protect. This can lead to a brief period in which the pods are running, but network policies that should apply to connections to and from the pods are not enforced. | ||||
| CVE-2025-1767 | 1 Kubernetes | 1 Kubelet | 2025-03-17 | 6.5 Medium |
| This CVE only affects Kubernetes clusters that utilize the in-tree gitRepo volume to clone git repositories from other pods within the same node. Since the in-tree gitRepo volume feature has been deprecated and will not receive security updates upstream, any cluster still using this feature remains vulnerable. | ||||
| CVE-2022-3162 | 2 Kubernetes, Redhat | 2 Kubernetes, Openshift | 2025-03-07 | 6.5 Medium |
| Users authorized to list or watch one type of namespaced custom resource cluster-wide can read custom resources of a different type in the same API group without authorization. Clusters are impacted by this vulnerability if all of the following are true: 1. There are 2+ CustomResourceDefinitions sharing the same API group 2. Users have cluster-wide list or watch authorization on one of those custom resources. 3. The same users are not authorized to read another custom resource in the same API group. | ||||