Approved changes feed: RSS · Atom

cpe:2.3:a:clastix:capsule-proxy:*:*:*:*:*:*:*:*

part: a version: * update: *

VendorClastix (22b1affa-e1e8-54d9-aa6c-69a1713e6135)
ProductCapsule Proxy (3f4bc956-660b-5dd7-8957-067f852e979c)
Edition*
Language*
Software edition*
Target software*
Target hardware*
Other*
NotesImported from purl2cpe mapping

PURL mappings

PURLSourceLast updated
pkg:github/clastix/capsule-proxy purl2cpe 2026-06-01 10:15:16.747082

Vulnerability references

IdentifiercpeApplicabilitySubmitteddb.gcve.eu detailsRationale
CVE:CVE-2023-48312 vulnerable 2026-06-08 06:14:26.859581 Authentication bypass using an empty token in capsule-proxy
CRITICAL (9.8)
capsule-proxy is a reverse proxy for the capsule operator project. Affected versions are subject to a privilege escalation vulnerability which is based on a missing check if the user is authenticated based on the `TokenReview` result. All the clusters running with the `anonymous-auth` Kubernetes API Server setting disable (set to `false`) are affected since it would be possible to bypass the token review mechanism, interacting with the upper Kubernetes API Server. This privilege escalation cannot be exploited if you're relying only on client certificates (SSL/TLS). This vulnerability has been addressed in version 0.4.6. Users are advised to upgrade.
Published: 2023-11-24T17:12:39.652Z
Updated: 2024-08-02T21:23:39.496Z
Reference links
Imported from gcve-enriched-dumps CVE data
CVE:CVE-2023-46254 vulnerable 2026-06-08 06:12:44.503521 Service accounts can see namespaces of other tenants in capsule-proxy
MEDIUM (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.
Published: 2023-11-06T18:34:13.555Z
Updated: 2024-08-02T20:37:40.135Z
Reference links
Imported from gcve-enriched-dumps CVE data
CVE:CVE-2022-23652 vulnerable 2026-06-08 05:40:58.127818 Privilege escalation using hop-by-hop Connection header
HIGH (8.8)
capsule-proxy is a reverse proxy for Capsule Operator which provides multi-tenancy in Kubernetes. In versions prior to 0.2.1 an attacker with a proper authentication mechanism may use a malicious `Connection` header to start a privilege escalation attack towards the Kubernetes API Server. This vulnerability allows for an exploit of the `cluster-admin` Role bound to `capsule-proxy`. There are no known workarounds for this issue.
Published: 2022-02-22T19:55:11.000Z
Updated: 2025-04-22T18:21:44.645Z
Reference links
Imported from gcve-enriched-dumps CVE data

Contribute

You can submit an edit proposal for this CPE entry or suggest a related product/vendor addition using the action button above.