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.
CVSS Rating: [CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N](https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N)

A security issue was discovered in Kubernetes where 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.

### Am I vulnerable?

Clusters are impacted by this vulnerability if all of the following are true:
- There are 2+ CustomResourceDefinitions sharing the same API group
- Users have cluster-wide list or watch authorization on one of those custom resources.
- The same users are not authorized to read another custom resource in the same API group.

#### Affected Versions

- Kubernetes kube-apiserver <= v1.25.3
- Kubernetes kube-apiserver <= v1.24.7
- Kubernetes kube-apiserver <= v1.23.13
- Kubernetes kube-apiserver <= v1.22.15

### How do I mitigate this vulnerability?

Upgrading the kube-apiserver to a fixed version mitigates this vulnerability.

Prior to upgrading, this vulnerability can be mitigated by avoiding granting cluster-wide list and watch permissions.

#### Fixed Versions

- Kubernetes kube-apiserver v1.25.4
- Kubernetes kube-apiserver v1.24.8
- Kubernetes kube-apiserver v1.23.14
- Kubernetes kube-apiserver v1.22.16

### Detection

Requests containing `..` in the request path are a likely indicator of exploitation. Request paths may be captured in API audit logs, or in kube-apiserver HTTP logs.

If you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io

#### Acknowledgements

This vulnerability was reported by Richard Turnbull of NCC Group as part of the Kubernetes Audit.

<!-- labels -->
/area security
/kind bug
/committee security-response
/label official-cve-feed
/sig api-machinery
/area apiserver

CVE-2022-3162: Unauthorized read of Custom Resources
This is a GitHub Issue
repo:kubernetes
owner:kubernetes
Title : CVE-2022-3162: Unauthorized read of Custom Resources
Issue date:

--- start body ---
CVSS Rating: [CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N](https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N)

A security issue was discovered in Kubernetes where 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.

### Am I vulnerable?

Clusters are impacted by this vulnerability if all of the following are true:
- There are 2+ CustomResourceDefinitions sharing the same API group
- Users have cluster-wide list or watch authorization on one of those custom resources.
- The same users are not authorized to read another custom resource in the same API group.

#### Affected Versions

- Kubernetes kube-apiserver <= v1.25.3
- Kubernetes kube-apiserver <= v1.24.7
- Kubernetes kube-apiserver <= v1.23.13
- Kubernetes kube-apiserver <= v1.22.15

### How do I mitigate this vulnerability?

Upgrading the kube-apiserver to a fixed version mitigates this vulnerability.

Prior to upgrading, this vulnerability can be mitigated by avoiding granting cluster-wide list and watch permissions.

#### Fixed Versions

- Kubernetes kube-apiserver v1.25.4
- Kubernetes kube-apiserver v1.24.8
- Kubernetes kube-apiserver v1.23.14
- Kubernetes kube-apiserver v1.22.16

### Detection

Requests containing `..` in the request path are a likely indicator of exploitation. Request paths may be captured in API audit logs, or in kube-apiserver HTTP logs.

If you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io

#### Acknowledgements

This vulnerability was reported by Richard Turnbull of NCC Group as part of the Kubernetes Audit.

<!-- labels -->
/area security
/kind bug
/committee security-response
/label official-cve-feed
/sig api-machinery
/area apiserver

--- end body ---
