The CVSS 9.9 rating for this HelmRelease vulnerability needs recalibration in your threat model. This isn't a remote code execution vector or an unauthenticated pathway — it requires a tenant who can already create HelmRelease CRs, making it a privilege escalation that exploits a specific architectural assumption: that CR creation is a 'safe' configuration action rather than a privileged one.
The deeper failure is architectural, not configurational. The HelmRelease controller model fundamentally trusts CR payloads in a way that RBAC cannot constrain. Once a tenant has permission to create HelmRelease objects, they can embed arbitrary manifests in chart templates and execute them with the controller's full ServiceAccount permissions — regardless of the RBAC policies meant to limit that tenant. This is the pattern security researchers call 'abstraction inversion': the system exposes a high-level primitive (HelmRelease, presented as a deployment action) that maps to a low-level capability (arbitrary manifest execution with elevated privileges).
The vulnerability has a documented lineage across Flux CD, ArgoCD, and operator-framework components. Each instance produces the same post-mortem analysis and the same remediation (controller-level input validation or scoped RBAC), which validates the blind spot for the next implementation. The community has repeatedly failed to treat this as a permanent design principle rather than an isolated incident.
What you should do: First, determine whether your HelmRelease controller's ServiceAccount actually holds cluster-admin in practice — the 9.9 rating assumes the ceiling, but the real blast radius depends on the actual permission scope. Second, audit your trust graph: if HelmRelease sits in a hub serving multiple tenant spokes, a single tenant exploit pivots through the hub to affect all spokes. Third, treat HelmRelease CR creation as a privileged operation in your admission policies — this isn't a deployment primitive, it's a privileged execution interface. Fourth, anticipate the exploitation window: historical patterns in this vulnerability class resolve within 60-90 days of disclosure once PoC tooling generalizes, even when initial EPSS scores are low (the 0.00322 here reflects the pre-generalization quiet window, not low risk). The compensating controls you already have may be informal and undocumented — probe for those shadows in your existing policies.