Namespace Injection in Kubernetes Capsule

A critical security vulnerability has been identified in Kubernetes Capsule v0.10.3 and earlier versions, allowing authenticated tenant users to inject arbitrary labels into system namespaces and bypass multi-tenant isolation controls. 

The vulnerability, tracked as GHSA-fcpm-6mxq-m5vv, was disclosed by security researcher Oliverbaehler and represents a significant threat to organizations relying on Capsule for Kubernetes multi-tenancy.

Key Takeaways
1. Capsule v0.10.3 allows tenant users to inject labels into system namespaces.
2. Label injection enables unauthorized cross-tenant resource access via TenantResource selectors.
3. Upgrade immediately to prevent privilege escalation.

Namespace Injection Vulnerability

The flaw resides in the namespace validation webhook logic within pkg/webhook/namespace/validation/patch.go:60-77, where a critical conditional check only validates tenant ownership when a namespace already contains a tenant label. 

The problematic code structure reveals the core issue:

Namespace Injection in Kubernetes Capsule

This vulnerability mirrors the attack pattern of CVE-2024-39690 but employs label injection instead of ownerReference manipulation. 

System namespaces like kube-system, default, and capsule-system lack the capsule.clastix.io/tenant label by default, making them susceptible to unauthorized label injection by authenticated tenant users, reads the advisory.

google

The exploitation process follows a systematic approach where attackers can inject malicious labels into unprotected system namespaces using standard kubectl patch commands:

Namespace Injection in Kubernetes Capsule

Subsequently, attackers can create malicious TenantResource objects that leverage namespace selectors to target these injected labels, effectively gaining access to system namespace resources. 

The attack chain progresses from Label injection(user-controlled) → Namespace selector(system matching) → TenantResource/Quota check(auth policy) → cross-tenant resource access, bypassing Capsule’s intended security boundaries.

Mitigations

The vulnerability affects multi-tenant Kubernetes clusters using Capsule v0.10.3 and potentially earlier versions, posing significant risks to organizations and cloud service providers offering Kubernetes-as-a-Service platforms. 

The security implications include multi-tenant isolation bypass, privilege escalation, potential data exfiltration from system namespaces, resource quota circumvention, and policy violations.

Attackers can exploit this vulnerability to access sensitive kube-system secrets containing cluster certificates and service account tokens, modify critical system configurations, and potentially achieve cluster-wide compromise. 

The vulnerability fundamentally undermines Capsule’s multi-tenant security model, allowing authenticated users to escape tenant boundaries and access system-level resources.

Organizations using affected Capsule versions should immediately upgrade to version 0.10.4, which addresses this critical security flaw. 

The patched version implements proper validation mechanisms to prevent unauthorized label injection into system namespaces, restoring the intended multi-tenant isolation boundaries essential for secure Kubernetes operations.

Safely detonate suspicious files to uncover threats, enrich your investigations, and cut incident response time. Start with an ANYRUN sandbox trial → 

googlenews
Florence Nightingale
Florence Nightingale is a senior security and privacy reporter, covering data breaches, cybercrime, malware, and data leaks from cyber space daily.