Every CVE Search/ Get API key

CVE-2023-46254

Service accounts can see namespaces of other tenants in capsule-proxy

4.3 MediumFix available

capsule-proxy is a reverse proxy for Capsule kubernetes multi-tenancy framework. A bug in the RoleBinding reflector used by capsule-proxy gives ServiceAccount tenant owners the right to list Namespaces of other tenants backed by the same owner kind and name. For example consider two tenants solar and wind. Tenant solar, owned by a ServiceAccount named tenant-owner in the Namespace solar. Tenant wind, owned by a ServiceAccount named tenant-owner in the Namespace wind. The Tenant owner solar would be able to list the namespaces of the Tenant wind and vice-versa, although this is not correct. The bug introduces an exfiltration vulnerability since allows the listing of Namespace resources of other Tenants, although just in some specific conditions: 1. capsule-proxy runs with the --disable-caching=false (default value: false) and 2. Tenant owners are ServiceAccount, with the same resource name, but in different Namespaces. This vulnerability doesn't allow any privilege escalation on the outer tenant Namespace-scoped resources, since the Kubernetes RBAC is enforcing this. This issue has been addressed in version 0.4.5. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Attack profile

How easy it is to exploit

Attack vector
Network
Complexity
Low
Privileges needed
Low
User interaction
None

What an attacker can affect

Confidentiality
Low
Integrity
None
Availability
None

Exploit likelihood

0.50%Up 0.5 points since Nov 7, 2023
90%50%10%1%

What each source reports

CVE List Score used 4.3

Service accounts can see namespaces of other tenants in capsule-proxy

capsule-proxy is a reverse proxy for Capsule kubernetes multi-tenancy framework. A bug in the RoleBinding reflector used by capsule-proxy gives ServiceAccount tenant owners the right to list Namespaces of other tenants backed by the same owner kind and name. For example consider two tenants solar and wind. Tenant solar, owned by a ServiceAccount named tenant-owner in the Namespace solar. Tenant wind, owned by a ServiceAccount named tenant-owner in the Namespace wind. The Tenant owner solar would be able to list the namespaces of the Tenant wind and vice-versa, although this is not correct. The bug introduces an exfiltration vulnerability since allows the listing of Namespace resources of other Tenants, although just in some specific conditions: 1. capsule-proxy runs with the --disable-caching=false (default value: false) and 2. Tenant owners are ServiceAccount, with the same resource name, but in different Namespaces. This vulnerability doesn't allow any privilege escalation on the outer tenant Namespace-scoped resources, since the Kubernetes RBAC is enforcing this. This issue has been addressed in version 0.4.5. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Record
CVE-2023-46254
CVSS 3.1
4.3 MediumCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Weakness
CWE-200
Updated
2026-11-02
EUVDEUVD-2023-2895 4.3

capsule-proxy is a reverse proxy for Capsule kubernetes multi-tenancy framework. A bug in the RoleBinding reflector used by capsule-proxy gives ServiceAccount tenant owners the right to list Namespaces of other tenants backed by the same owner kind and name. For example consider two tenants solar and wind. Tenant solar, owned by a ServiceAccount named tenant-owner in the Namespace solar. Tenant wind, owned by a ServiceAccount named tenant-owner in the Namespace wind. The Tenant owner solar would be able to list the namespaces of the Tenant wind and vice-versa, although this is not correct. The bug introduces an exfiltration vulnerability since allows the listing of Namespace resources of other Tenants, although just in some specific conditions: 1. capsule-proxy runs with the --disable-caching=false (default value: false) and 2. Tenant owners are ServiceAccount, with the same resource name, but in different Namespaces. This vulnerability doesn't allow any privilege escalation on the outer tenant Namespace-scoped resources, since the Kubernetes RBAC is enforcing this. This issue has been addressed in version 0.4.5. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Record
EUVD-2023-2895
CVSS 3.1
4.3 MediumCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Updated
2026-11-03
GitHub AdvisoriesGHSA-6758-979h-249x 4.3

capsule-proxy service discloses Namespaces of colliding tenants to owners of different tenants with the same ServiceAccount name

Summary

A bug in the RoleBinding reflector used by capsule-proxy gives ServiceAccount tenant owners the right to list Namespaces of other tenants backed by the same owner kind and name.

Details

  • Tenant solar, owned by a ServiceAccount named tenant-owner in the Namespace solar
  • Tenant wind, owned by a ServiceAccount named tenant-owner in the Namespace wind

Please, notice the same ServiceAccount name, although in different namespaces.

The Tenant owner solar would be able to list the namespaces of the Tenant wind and vice-versa, although this is not correct.

The bug introduces an exfiltration vulnerability since allows the listing of Namespace resources of other Tenants, although just in some specific conditions:

  1. capsule-proxy runs with the --disable-caching=false (default value: false)
  2. Tenant owners are ServiceAccount, with the same resource name, but in different Namespaces.

The CVE doesn't allow any privilege escalation on the outer tenant Namespace-scoped resources, since the Kubernetes RBAC is enforcing this.

Record
GHSA-6758-979h-249x
CVSS 3.1
4.3 MediumCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Weakness
CWE-200
Updated
2026-11-02
NVD 4.3

capsule-proxy is a reverse proxy for Capsule kubernetes multi-tenancy framework. A bug in the RoleBinding reflector used by capsule-proxy gives ServiceAccount tenant owners the right to list Namespaces of other tenants backed by the same owner kind and name. For example consider two tenants solar and wind. Tenant solar, owned by a ServiceAccount named tenant-owner in the Namespace solar. Tenant wind, owned by a ServiceAccount named tenant-owner in the Namespace wind. The Tenant owner solar would be able to list the namespaces of the Tenant wind and vice-versa, although this is not correct. The bug introduces an exfiltration vulnerability since allows the listing of Namespace resources of other Tenants, although just in some specific conditions: 1. capsule-proxy runs with the --disable-caching=false (default value: false) and 2. Tenant owners are ServiceAccount, with the same resource name, but in different Namespaces. This vulnerability doesn't allow any privilege escalation on the outer tenant Namespace-scoped resources, since the Kubernetes RBAC is enforcing this. This issue has been addressed in version 0.4.5. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Record
CVE-2023-46254
CVSS 3.1
4.3 MediumCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Weakness
CWE-200
Updated
2026-11-02
OSV 4.3

Service accounts can see namespaces of other tenants in capsule-proxy

capsule-proxy is a reverse proxy for Capsule kubernetes multi-tenancy framework. A bug in the RoleBinding reflector used by capsule-proxy gives ServiceAccount tenant owners the right to list Namespaces of other tenants backed by the same owner kind and name. For example consider two tenants solar and wind. Tenant solar, owned by a ServiceAccount named tenant-owner in the Namespace solar. Tenant wind, owned by a ServiceAccount named tenant-owner in the Namespace wind. The Tenant owner solar would be able to list the namespaces of the Tenant wind and vice-versa, although this is not correct. The bug introduces an exfiltration vulnerability since allows the listing of Namespace resources of other Tenants, although just in some specific conditions: 1. capsule-proxy runs with the --disable-caching=false (default value: false) and 2. Tenant owners are ServiceAccount, with the same resource name, but in different Namespaces. This vulnerability doesn't allow any privilege escalation on the outer tenant Namespace-scoped resources, since the Kubernetes RBAC is enforcing this. This issue has been addressed in version 0.4.5. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Record
CVE-2023-46254
CVSS 3.1
4.3 MediumCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Weakness
CWE-200
Updated
2026-11-02
OSVGHSA-6758-979h-249x 4.3

capsule-proxy service discloses Namespaces of colliding tenants to owners of different tenants with the same ServiceAccount name

Summary

A bug in the RoleBinding reflector used by capsule-proxy gives ServiceAccount tenant owners the right to list Namespaces of other tenants backed by the same owner kind and name.

Details

  • Tenant solar, owned by a ServiceAccount named tenant-owner in the Namespace solar
  • Tenant wind, owned by a ServiceAccount named tenant-owner in the Namespace wind

Please, notice the same ServiceAccount name, although in different namespaces.

The Tenant owner solar would be able to list the namespaces of the Tenant wind and vice-versa, although this is not correct.

The bug introduces an exfiltration vulnerability since allows the listing of Namespace resources of other Tenants, although just in some specific conditions:

  1. capsule-proxy runs with the --disable-caching=false (default value: false)
  2. Tenant owners are ServiceAccount, with the same resource name, but in different Namespaces.

The CVE doesn't allow any privilege escalation on the outer tenant Namespace-scoped resources, since the Kubernetes RBAC is enforcing this.

Record
GHSA-6758-979h-249x
CVSS 3.1
4.3 MediumCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Weakness
CWE-200
Updated
2026-11-02

Affected products

Affected packages

Affected packages
PackageAffectedFixed
github.com/projectcapsule/capsule
Go
through 0.4.4
0.4.5
github.com/projectcapsule/capsule-proxy
Go
through 0.4.4
0.4.5
github.com/projectcapsule/capsule
Go
before 0.4.5
0.4.5
github.com/projectcapsule/capsule-proxy
Go
before 0.4.5
0.4.5

History

History
RecordedChangedSources
aliases, publishedEUVD
first indexedCVE List, GitHub Advisories, NVD, OSV

Dates are when Every CVE recorded each change. Upstream dates may differ.

In short

CVE-2023-46254 is a medium vulnerability (CVSS 4.3) in Clastix Capsule, published November 6, 2023. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 0.50%, the 43rd percentile. Fixed in github.com/projectcapsule/capsule 0.4.5.

References

MoveEnter Open