Red Hat ACM CVE-2026-67567

Exploitation requires an authenticated tenant identity (CVSS PR:L) that has been granted RBAC permission to create HelmRelease custom resources handled by the multicloud-operators-subscription HelmRelease controller in RHACM 2.x. The concrete prerequisite is this delegated HelmRelease-create capability combined with a deployment where that controller reconciles tenant-supplied charts using its own elevated ServiceAccount. No user interaction and no high privileges are needed (UI:N, PR:L). Exploitation is limited to environments that actually grant HelmRelease creation to non-admin tenants; clusters where only cluster administrators can create HelmRelease CRs, or where admission policy constrains the controller, are not exposed. Network reachability to the Kubernetes API server is required (AV:N).

The signals point to a genuine high priority rather than an inflated CVSS. The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H = 9.9) indicates remote, low-complexity exploitation by an authenticated low-privileged tenant, with a scope change reflecting the crossing of the namespace/tenant security boundary into cluster-wide impact and full C/I/A loss. The one meaningful precondition (PR:L) is exactly the multi-tenant model RHACM is built for, so in shared clusters the barrier is low. No EPSS score, SSVC decision, or POC indicator was provided in the input, so exploitation probability cannot be quantified and there is no confirmed public exploit; it is also not in CISA KEV, so there is no evidence of active exploitation. The CWE-441 confused-deputy pattern is well understood and straightforward to trigger for anyone with HelmRelease create permissions, which keeps real-world risk high for any environment that delegates HelmRelease creation to tenants; single-tenant or tightly-restricted-RBAC deployments face materially lower exposure.

A tenant with delegated permission to create HelmRelease CRs in their own namespace submits a crafted Helm chart whose templates declare cluster-scoped objects such as a ClusterRoleBinding granting cluster-admin to the tenant, plus resources in namespaces they do not own. The HelmRelease controller renders and applies these manifests under its own elevated ServiceAccount, so the objects are created cluster-wide, giving the tenant control over the entire cluster. No public POC is identified in the input, but the low attack complexity and network vector make exploitation straightforward for anyone holding HelmRelease create rights.