CVE-2026-73122

The EPSS score of 0.00212 for CVE-2026-73122 fundamentally conflicts with its CVSS 7.7 rating — but the tension reveals something important about how this vulnerability should be prioritized, not just how it should be scored. This is a post-compromise privilege escalation in Red Hat Advanced Cluster Management (RHACM). A threat actor must first compromise a managed cluster agent before they can exploit this flaw to harvest Git and Helm credentials from the hub. That prerequisite dramatically changes the threat model: this isn't an initial access vector, it's a compound attack chain. The EPSS correctly captures that the probability of someone chaining both steps is low — until you consider that the agent runs workloads that get compromised through the same container escape and supply chain paths as everything else. In environments where multi-tenant RHACM hubs are common — managed service providers, internal platform teams, shared CI/CD infrastructure — agent compromise via vulnerable operators or third-party Helm charts is not exceptional, it's expected. The "post-compromise" qualifier that downgrades this vulnerability has been systematically abused across similar multi-cluster trust failures (CVE-2021-30465 in ArgoCD, Vault and Pulumi patterns), each of which was scored as secondary risk and then actively exploited. The real blast radius is not linear — it's supernova. One compromised agent harvests Git and Helm credentials for every tenant on the hub. Those credentials aren't dormant secrets; they're active tokens to source repositories and package registries. The attack path extends from "read a ConfigMap" to "push malicious code to production across multiple unrelated organizations." CVSS 7.7 captures information disclosure in a vacuum; it cannot weight this cascade. This vulnerability is also an emergent property of the hub-managed cluster trust model, not a simple bug someone introduced. The hub needs read access to cluster secrets to pull Helm charts, sync Git sources, and orchestrate deployments — that trust relationship must exist for multi-cluster management to function. The fix won't eliminate the trust requirement; it will relocate it. Red Hat's RBAC changes will narrow the blast radius for new deployments while legacy channels likely remain exposed, exactly as we've seen with Istio's authorization policies and Vault's namespace isolation. The detection gap is critical. The credential harvest is silent — no malware signature, no anomalous outbound pattern your SIEM will catch unless you've specifically instrumented the hub for hub-to-tenant credential access monitoring. The exploitation window isn't a single moment; it's potentially months of credential collection before those source repos get used for supply chain injection. The EPSS treats exploitation as a discrete event, but this vulnerability's actual threat profile is a slow burn that most detection tooling isn't looking for. Ask yourself: is your organization even auditing hub credential access patterns? If not, the EPSS score is irrelevant — the real risk is that this flaw will go unnoticed even after it's patched. For single-tenant deployments, the cross-tenant harvest vector disappears, but the hub-managed cluster trust relationship remains. The agent can still read every credential on the hub for its own workloads, and weaker monitoring assumptions about isolated infrastructure may actually make agent compromise quieter and longer-dwell. The question isn't whether single-tenant hubs are meaningfully safer — it's whether any RHACM deployment should assume hub compromise is a realistic endpoint and design detection and containment around that assumption.

Reviewed through automated stages and approved by a human before publication.