Page 7 of 49 results (0.010 seconds)

CVSS: 6.5EPSS: 0%CPEs: 10EXPL: 0

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. La biblioteca de servicio de cliente de Kubernetes registra los encabezados de solicitud en niveles de detalle de 7 o superior. Esto puede revelar las credenciales a los usuarios no autorizados a través de los registros o la salida del comando. • http://www.openwall.com/lists/oss-security/2020/10/16/2 https://access.redhat.com/errata/RHSA-2019:4052 https://access.redhat.com/errata/RHSA-2019:4087 https://github.com/kubernetes/kubernetes/issues/81114 https://security.netapp.com/advisory/ntap-20190919-0003 https://access.redhat.com/security/cve/CVE-2019-11250 https://bugzilla.redhat.com/show_bug.cgi?id=1740434 • CWE-532: Insertion of Sensitive Information into Log File •

CVSS: 6.5EPSS: 0%CPEs: 9EXPL: 0

The kubectl cp command allows copying files between containers and the user machine. To copy files from a container, Kubernetes runs tar inside the container to create a tar archive, copies it over the network, and kubectl unpacks it on the user’s machine. If the tar binary in the container is malicious, it could run any code and output unexpected, malicious results. An attacker could use this to write files to any path on the user’s machine when kubectl cp is called, limited only by the system permissions of the local user. Kubernetes affected versions include versions prior to 1.13.9, versions prior to 1.14.5, versions prior to 1.15.2, and versions 1.1, 1.2, 1.4, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 1.10, 1.11, 1.12. • https://access.redhat.com/errata/RHBA-2019:2794 https://access.redhat.com/errata/RHBA-2019:2816 https://access.redhat.com/errata/RHBA-2019:2824 https://access.redhat.com/errata/RHSA-2019:3239 https://access.redhat.com/errata/RHSA-2019:3811 https://github.com/kubernetes/kubernetes/issues/80984 https://groups.google.com/d/msg/kubernetes-security-announce/vUtEcSEY6SM/v2ZZxsmtFQAJ https://security.netapp.com/advisory/ntap-20190919-0003 https://access.redhat.com/security/cve/CVE-2019-11249& • CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') CWE-61: UNIX Symbolic Link (Symlink) Following •

CVSS: 8.2EPSS: 62%CPEs: 50EXPL: 0

The debugging endpoint /debug/pprof is exposed over the unauthenticated Kubelet healthz port. The go pprof endpoint is exposed over the Kubelet's healthz port. This debugging endpoint can potentially leak sensitive information such as internal Kubelet memory addresses and configuration, or for limited denial of service. Versions prior to 1.15.0, 1.14.4, 1.13.8, and 1.12.10 are affected. The issue is of medium severity, but not exposed by the default configuration. • https://github.com/kubernetes/kubernetes/issues/81023 https://groups.google.com/d/msg/kubernetes-security-announce/pKELclHIov8/BEDtRELACQAJ https://security.netapp.com/advisory/ntap-20190919-0003 • CWE-419: Unprotected Primary Channel CWE-862: Missing Authorization •

CVSS: 7.8EPSS: 0%CPEs: 2EXPL: 1

In kubelet v1.13.6 and v1.14.2, containers for pods that do not specify an explicit runAsUser attempt to run as uid 0 (root) on container restart, or if the image was previously pulled to the node. If the pod specified mustRunAsNonRoot: true, the kubelet will refuse to start the container as root. If the pod did not specify mustRunAsNonRoot: true, the kubelet will run the container as uid 0. En kubelet v1.13.6 y v1.14.2, los contenedores para pods que no especifican un intento runAsUser explícito de ejecutarse como uid 0 (raíz) en el reinicio del contenedor, o si la imagen se extrajo previamente en el nodo. Si el pod especificado mustRunAsNonRoot: true, el kubelet se negará a iniciar el contenedor como root. • https://github.com/kubernetes/kubernetes/issues/78308 https://security.netapp.com/advisory/ntap-20190919-0003 • CWE-264: Permissions, Privileges, and Access Controls CWE-703: Improper Check or Handling of Exceptional Conditions •

CVSS: 8.1EPSS: 0%CPEs: 8EXPL: 0

The Kubernetes kube-apiserver mistakenly 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). Kubernetes affected versions include versions prior to 1.13.9, versions prior to 1.14.5, versions prior to 1.15.2, and versions 1.7, 1.8, 1.9, 1.10, 1.11, 1.12. El kube-apiserver de Kubernetes permite por error el acceso a un recurso personalizado de ámbito de clúster si la solicitud se realiza como si el recurso estuviera con espacio de nombres. Las autorizaciones para el recurso al que se tiene acceso de esta manera se aplican mediante roles y enlaces de roles dentro del espacio de nombres, lo que significa que un usuario con acceso solo a un recurso en un espacio de nombres podría crear, ver actualizar o eliminar el recurso de ámbito de clúster (según sus privilegios de rol de espacio de nombres). • https://access.redhat.com/errata/RHBA-2019:2816 https://access.redhat.com/errata/RHBA-2019:2824 https://access.redhat.com/errata/RHSA-2019:2690 https://access.redhat.com/errata/RHSA-2019:2769 https://github.com/kubernetes/kubernetes/issues/80983 https://groups.google.com/d/msg/kubernetes-security-announce/vUtEcSEY6SM/v2ZZxsmtFQAJ https://security.netapp.com/advisory/ntap-20190919-0003 https://access.redhat.com/security/cve/CVE-2019-11247 https://bugzilla.redhat.com/show_bug.cgi?id=1 • CWE-20: Improper Input Validation CWE-284: Improper Access Control CWE-863: Incorrect Authorization •