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.

Affected: Go: github.com/kubernetes/kubernetes

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.

Affected: openEuler:20.03-LTS-SP3: kubernetes

Container cluster management.

Security Fix(es):

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.(CVE-2022-3162)

Users may have access to secure endpoints in the control plane network. Kubernetes clusters are only affected if an untrusted user can modify Node objects and send proxy requests to them. Kubernetes supports node proxying, which allows clients of kube-apiserver to access endpoints of a Kubelet to establish connections to Pods, retrieve container logs, and more. While Kubernetes already validates the proxying address for Nodes, a bug in kube-apiserver made it possible to bypass this validation. Bypassing this validation could allow authenticated requests destined for Nodes to to the API server's private network.(CVE-2022-3294)

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…

kubernetes1.24-apiserver-1.24.11-1.1 on GA media

go-yaml: Denial of Service in go-yaml golang: net/http: improper sanitization of Transfer-Encoding header golang: archive/tar: github.com/vbatts/tar-split: unbounded memory consumption when reading headers golang: net/http/httputil: ReverseProxy should not forward unparseable query parameters cri-o: incorrect handling of the supplementary groups python-scciclient: missing server certificate verification kubernetes: Unauthorized read of Custom Resources kube-apiserver: Aggregated API server can cause clients to be redirected (SSRF) OpenShift: Missing HTTP Strict Transport Security cri-o: Security regression of CVE-2022-27652 golang: net/http: handle server errors after sending GOAWAY golang: compress/gzip: stack exhaustion in Reader.Read golang: net/http/httputil: NewSingleHostReverseProxy - omit X-Forwarded-For not working golang: math/big: decoding big.Float and big.Rat types can panic if the encoded message is too short, potentially allowing a denial of service golang: net/url: JoinPath does not strip relative path components in all circumstances golang: regexp/syntax: limit memory used by parsing regexps

Withdrawn by the publisher.

Affected: Ubuntu:Pro:20.04:LTS: kubernetes, Ubuntu:22.04:LTS: kubernetes, Ubuntu:24.04:LTS: kubernetes

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.

Ein entfernter, authentisierter Angreifer kann eine Schwachstelle in Kubernetes ausnutzen, um Informationen offenzulegen.