CVE-2025-55205
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-08-18

Last updated on: 2025-08-18

Assigner: GitHub, Inc.

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-08-18
Last Modified
2025-08-18
Generated
2026-05-07
AI Q&A
2025-08-18
EPSS Evaluated
2026-05-05
NVD
Affected Vendors & Products
Showing 2 associated CPEs
Vendor Product Version / Range
clastix capsule 0.10.3
clastix capsule 0.10.4
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-863 The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

CVE-2025-55205 is a namespace label injection vulnerability in Capsule (a multi-tenancy framework for Kubernetes) versions 0.10.3 and earlier. Authenticated tenant users with permission to patch namespaces can inject arbitrary labels into critical system namespaces like kube-system, default, and capsule-system. Because these system namespaces lack tenant labels by default, Capsule's validation webhook fails to properly verify tenant ownership, allowing unauthorized label injection. This bypasses Capsule's multi-tenant isolation, enabling privilege escalation and unauthorized cross-tenant resource access. [2]


How can this vulnerability impact me? :

This vulnerability can lead to privilege escalation and authorization bypass in Kubernetes clusters using Capsule. Attackers can inject labels into system namespaces to trick TenantResource selectors, gaining unauthorized access to resources across tenants. This can result in data exfiltration from sensitive system namespaces, bypassing resource quotas and policies, and potentially compromising the entire cluster by accessing critical system components. [2]


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

The vulnerability violates fundamental security boundaries and tenant isolation, potentially leading to unauthorized access and exfiltration of sensitive data. Such breaches can result in non-compliance with data protection regulations like GDPR and HIPAA, which require strict access controls and data confidentiality. Therefore, exploitation of this vulnerability could cause compliance failures and legal consequences. [2]


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by checking if system namespaces (such as kube-system, default, capsule-system) have unauthorized tenant labels injected, specifically the label "capsule.clastix.io/tenant". You can use kubectl commands to inspect these namespaces for unexpected labels. For example, run: `kubectl get namespace kube-system -o json | jq '.metadata.labels'` and check for the presence of tenant labels. Additionally, attempts to patch these namespaces with tenant labels by authenticated tenant users should fail if the system is patched. You can test detection by attempting to patch a system namespace with a tenant label using: `kubectl patch namespace kube-system -p '{"metadata":{"labels":{"capsule.clastix.io/tenant":"<tenant-name>"}}}' --type=merge` and verify if the patch is denied. [1, 2]


What immediate steps should I take to mitigate this vulnerability?

The immediate mitigation step is to upgrade Capsule to version 0.10.4 or later, where the vulnerability is fixed. This update includes improved namespace patch validation logic that prevents tenant users from injecting labels into system namespaces. Until the upgrade, restrict tenant users' permissions to patch namespaces, especially system namespaces, to prevent exploitation. Monitoring and auditing namespace label changes can also help detect attempts to exploit this vulnerability. [1, 2]


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart