Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
11 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/projectcapsule/capsule >= 0.13.0, < 0.13.7
Fixed in
0.13.7· Vendor fix available
Issue
A parameter order bug in internal/webhook/tenant/validation/hostnameregex.go causes the hostnameRegexHandler.OnUpdate webhook to validate the old Tenant object's AllowedHostnames.Regex instead of the new one being submitted. This allows an invalid (malformed) regex to bypass admission validation and be persisted to etcd, causing a Denial of Service for all Ingress operations within the affected tenant. Details The TypedHandler[T] interface defines OnUpdate as: The dispatcher in handler.go:93 calls: However, hostnameRegexHandler.OnUpdate in hostnameregex.go declares its parameters in reversed order: All 11 other handlers in the same package declare (tnt, old) correctly. hostnameregex.go is the only one with the swap. As a result, when a Cluster Admin updates Tenant.Spec.IngressOptions.AllowedHostnames.Regex to a malformed value, the webhook compiles the previous valid regex and returns Allow. The malformed regex is then written to etcd. Subsequently, every Ingress CREATE or…
Recommended action: Upgrade to 0.13.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Capsule lets a cluster administrator forbid specific metadata keys that tenant owners must not place on their own resources: Tenant.spec.namespaceOptions.forbiddenLabels / forbiddenAnnotations (namespaces), Tenant.spec.serviceOptions.forbiddenLabels / forbiddenAnnotations (Services), and the cluster-wide forbidden worker-node labels/annotations. These lists are an isolation control — they exist to stop a tenant owner from setting metadata that other controllers or admission plugins key on (Pod Security Admission labels, kubernetes.io/metadata.name, LoadBalancer/externalIP service annotations, scheduler annotations, vendor labels that grant network reach, etc.). The validating webhooks enforce them through api.ValidateForbidden, which calls ForbiddenListSpec.ExactMatch(key) for every key the tenant submits. ExactMatch is broken. It sorts the denied list case-insensitively (sort.SliceStable with a strings.ToLower comparator) and then performs a byte-order binary search…
Recommended action: Upgrade to 0.13.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/projectcapsule/capsule >= 0.13.0, < 0.13.7
Fixed in
0.13.7· Vendor fix available
Issue
A validation bug in internal/webhook/tenant/validation/forbiddenannotationsregex.go allows an invalid ForbiddenAnnotations.Regex value to bypass Tenant admission on update. The webhook compiles ForbiddenLabels.Regex for both labels and annotations, so a malformed annotations regex can be persisted. Once stored, namespace admission later evaluates the bad regex through pkg/api/forbiddenlist.go, where regexp.MustCompile can panic and cause admission failure. Details In internal/webhook/tenant/validation/forbiddenannotationsregex.go, OnUpdate validates the new Tenant object, but the loop compiles tnt.Spec.NamespaceOptions.ForbiddenLabels.Regex for both labels and annotations. That means an invalid ForbiddenAnnotations.Regex is never validated if ForbiddenLabels.Regex is valid. Relevant paths: - internal/webhook/tenant/validation/forbiddenannotationsregex.go - internal/webhook/namespace/validation/usermetadata.go - pkg/api/forbiddenlist.go Namespace admission later calls…
Recommended action: Upgrade to 0.13.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/projectcapsule/capsule >= 0.13.0, <= 0.13.7
Fixed in
0.13.8· Vendor fix available
Issue
CVE-2026-22872 (GHSA-qjjm-7j9w-pw72) reported that a Tenant Owner could create cluster-scoped resources (e.g. ClusterRole, ValidatingWebhookConfiguration) through a TenantResource, because the controller applies them with its cluster-admin ServiceAccount and SetNamespace is ineffective for cluster-scoped kinds. The v0.13.0 fix added a cluster-scope rejection guard, but only on the NamespacedItems selection path (ResourceReference.LoadResources - IsNamespacedGVK, error "cluster-scoped kind ... is not allowed"). The RawItems create path — the exact vector the original advisory named — and the Generators path were not given this guard. The vulnerability therefore persists in all releases v0.13.0 through v0.13.7 and on trunk HEAD (8d89d6865d). Details TenantResource reconcile flow: - internal/controllers/resources/namespaced.go reconcile() obtains the apply client via loadClient(); by default (impersonation off, no Spec.ServiceAccount) this is the manager client whose SA is bound…
Recommended action: Upgrade to 0.13.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
CapsuleConfiguration.Spec.NodeMetadata.ForbiddenLabels.Regex and ForbiddenAnnotations.Regex are never validated by any admission webhook. A Cluster Admin can persist a malformed regex to etcd without being blocked. Once stored, every Node CREATE, UPDATE, or PATCH request triggers regexp.MustCompile() in pkg/api/forbiddenlist.go:36, which panics and crashes the node admission webhook — causing a cluster-wide Denial of Service for all Node operations. Root cause internal/webhook/tenant/validation/ contains dedicated regex validators for every Tenant regex field (hostname, storageclass, ingressclass, containerregistry, etc.). internal/webhook/cfg/ contains no regex validator at all — only owners.go, serviceaccount.go, and warnings.go. The downstream consumer internal/webhook/node/usermetadata.go calls: Which routes to pkg/api/forbiddenlist.go:36: Unlike regexp.Compile, regexp.MustCompile panics instead of returning an error. Since no webhook validates the CapsuleConfiguration…
Recommended action: Upgrade to 0.13.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/projectcapsule/capsule >= 0.13.0, < 0.13.6
Fixed in
0.13.6· Vendor fix available
Issue
Capsule v0.13.2 webhook rules contain namespace/finalize (singular) instead of namespaces/finalize (plural). K8s requires plural. The finalize defense from CVE-2026-30963 fix is absent. Details PUT to /api/v1/namespaces/<ns/finalize has resource=namespaces (plural). The singular rule never matches. matchPolicy: Equivalent does not compensate. PoC Confirmed on kind + Capsule v0.13.2. alice (non-admin with namespaces/finalize RBAC): kubectl label --as=alice = DENIED (control). kubectl replace --raw /finalize --as=alice = 200 OK (bypass). Tenant label changed. Impact Namespace tenant-label hijack. Same threat model as CVE-2026-30963. One-char fix: namespace/finalize - namespaces/finalize. The CVE-2026-30963 fix in Capsule v0.13.2 added subresource entries to the namespace validating webhook, but charts/capsule/templates/configuration.yaml line 105 contains a singular/plural typo: namespace/finalize instead of namespaces/finalize. Kubernetes webhook rules require the plural…
Recommended action: Upgrade to 0.13.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
TenantResource RawItems Cluster-Scoped Resource Creation Vulnerability Summary The Capsule Controller runs with cluster-admin privileges. Although the TenantResource RawItems processing logic forcibly sets the namespace, this is ineffective for cluster-scoped resources. Tenant administrators can leverage the Controller's elevated privileges to create cluster-scoped resources (such as ClusterRole and ValidatingWebhookConfiguration) that they cannot create directly, achieving cross-tenant privilege escalation and cluster-level attacks. --- Details Vulnerability Location File: internal/controllers/resources/processor.go Function: HandleSection() Lines: 247-285 Core Issues 1. Excessive Controller Privileges: The Controller's ServiceAccount is bound to the cluster-admin ClusterRole 2. Missing Resource Scope Validation: Although the code calls obj.SetNamespace(ns.Name), this is ineffective for cluster-scoped resources (ClusterRole, ValidatingWebhookConfiguration, etc.), as the Kubernetes…
Recommended action: Upgrade to 0.13.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
To defend against namespace hijacking achieved through update/patch operations on namespaces, Capsule uses a webhook to validate update requests targeting namespaces. However, in Kubernetes, the namespace/finalize and namespace/status subresource APIs can also modify various fields of a namespace, including the metadata field. The webhook does not define interception rules for these subresources. As a result, if a tenant administrator has permission to modify namespace/status or namespace/finalize, they can successfully perform namespace hijacking. Details When Capsule uses a ValidatingWebhookConfiguration to intercept changes to namespace resources, it does not intercept modification requests initiated through namespace subresource APIs (see: https://github.com/projectcapsule/capsule/blob/main/charts/capsule/templates/validatingwebhookconfiguration.yaml#L193). Through subresource APIs, it is still possible to modify the metadata field of a namespace resource, enabling…
Recommended action: Upgrade to 0.13.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A namespace label injection vulnerability in Capsule v0.10.3 allows authenticated tenant users to inject arbitrary labels into system namespaces (kube-system, default, capsule-system), bypassing multi-tenant isolation and potentially accessing cross-tenant resources through TenantResource selectors. This vulnerability enables privilege escalation and violates the fundamental security boundaries that Capsule is designed to enforce. Details The vulnerability exists in the namespace validation webhook logic located in pkg/webhook/namespace/validation/patch.go:60-77. The critical flaw is in the conditional check that only validates tenant ownership when a namespace already has a tenant label: Root Cause Analysis: 1. Missing Default Protection: System namespaces (kube-system, default, capsule-system) do not have the capsule.clastix.io/tenant label by default 2. Bypass Logic: The webhook only enforces tenant ownership validation when the target namespace already belongs to a tenant…
Recommended action: Upgrade to 0.10.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Attack Vector Then, let me briefly explain the reasons for the errors mentioned above: 1. The 'kubectl edit' command was used to patch the namespace, but this operation requires both 'get' and 'patch' permissions, hence the error. One should use methods like 'curl' to directly send a PATCH request; 2. The webhook does not intercept patch operations on 'kube-system' because 'kube-system' does not have an ownerReference. Below are my detailed reproduction steps 1. Create a test cluster kind create cluster --image=kindest/node:v1.24.15 --name=k8s 2. Install the capsule helm install capsule projectcapsule/capsule -n capsule-system --create-namespace 3. Create a tenant 4. Create user alice 5. Patch kube-system (The first command is executed in the current shell, while the 2nd and 3rd commands require a different shell window because the current shell is being used as a proxy.) 7. Check the result The kube-system is patched successfully. Summary The tenant-owner can patch any arbitrary…
Recommended action: Upgrade to 0.7.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 0.4.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.