Description

A flaw was found in the multicloud-operators-subscription component. This vulnerability allows a tenant, who has the ability to create HelmRelease custom resources (CRs), to bypass existing security controls. The system's HelmRelease controller processes Helm chart templates using its own elevated ServiceAccount privileges without proper validation. This enables the tenant to deploy arbitrary resources across the entire cluster, leading to a significant security compromise.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.9",
  "pubDate": "2026-08-20T21:17:07.403Z",
  "pubdate": "2026-08-20T21:17:07.403Z",
  "executiveSummary": "A privilege escalation vulnerability exists in the multicloud-operators-subscription component, specifically within the handling of HelmRelease custom resources (CRs). The vulnerability arises due to the HelmRelease controller processing Helm chart templates with elevated ServiceAccount privileges without implementing appropriate validation or restriction mechanisms.\nThe primary impact of this security flaw is a severe cluster-wide compromise. An authenticated tenant possessing the capability to create HelmRelease custom resources can leverage this privilege mismatch to bypass established security boundaries and isolation controls. By deploying arbitrary and unauthorized resources across the entire Kubernetes cluster, the malicious tenant effectively gains the elevated privileges associated with the controller's ServiceAccount.\nThe risk implications are critical, as multi-tenant isolation is entirely subverted, potentially leading to unauthorized data access, resource manipulation, or complete cluster takeover. Exploitation requires the attacker to have preliminary access to create HelmRelease custom resources within the cluster, enabling them to interact with the vulnerable multicloud-operators-subscription component and induce the controller into executing arbitrary template deployments using over-permissioned credentials.",
  "technicalDetails": "The vulnerability is rooted in the privilege management and validation logic of the HelmRelease controller within the multicloud-operators-subscription component. Specifically, the root cause involves the controller executing Helm chart template rendering and resource instantiation operations using its own highly privileged ServiceAccount, rather than impersonating the originating tenant or applying strict authorization and validation boundaries to the supplied HelmRelease custom resources.\nThe vulnerable component is the HelmRelease controller associated with multicloud-operators-subscription. The attack vector requires the adversary to possess permissions to create HelmRelease custom resources within their scoped tenant environment. Because authentication and authorization checks fail to restrict the scope of deployable resources, the tenant can craft malicious Helm chart templates designed to deploy arbitrary cluster-scoped or cross-tenant resources.\nThe step-by-step attack flow proceeds as follows: First, the authenticated tenant with custom resource creation capabilities defines a malicious HelmRelease custom resource containing templates targeting restricted namespaces or cluster-scoped objects. Second, the tenant submits this custom resource to the Kubernetes API server. Third, the vulnerable HelmRelease controller detects the new custom resource and automatically processes the embedded Helm chart templates. Fourth, because the controller executes these operations utilizing its own elevated ServiceAccount privileges, the API server accepts and applies the arbitrary resources instantiated by the template. Finally, the attacker achieves complete cluster compromise, bypassing tenant boundaries and existing security controls without requiring direct access to the controller's underlying credentials."
}