CVE-2026-56160

CVE-2026-56160 in Azure Red Hat OpenShift carries a 9.1 CVSS but an EPSS score of only 0.00652. The temptation is to treat this as a theoretical risk that won't materialize in practice — but that reading misunderstands what makes authorization flaws in managed platforms categorically different from typical application vulnerabilities. The gap between the two scores reflects what each model measures. CVSS captures severity given exploitation — it assumes the flaw exists and asks how bad it would be. EPSS models whether active exploitation is likely in the wild, driven by threat intelligence, exploit availability, and time-to-exploit. Neither captures the blast radius characteristic unique to managed platform authorization failures: the vulnerable surface isn't a feature you can disable or a version you can avoid, it's the platform's core isolation contract with every tenant. The 'authorized attacker' language in the CVSS vector deserves scrutiny. In authorization flaws, this often describes a legitimate RBAC principal that shouldn't have the privilege being obtained — not an external attacker. Whether this allows tenant A to read tenant B's secrets within the cluster, or enables escape from tenant isolation into the Azure control plane, changes the risk profile dramatically. The distinction matters: the former is a multi-tenant data leak; the latter is infrastructure compromise. Without the patch diff, you cannot determine which applies. For defenders, the practical posture is: confirm whether your ARO cluster uses pod identity tokens, mutating webhooks, or non-default networking topologies, because these configurations determine whether the exploitable population includes your workloads. Treat the CVSS severity as the floor, not the ceiling — the EPSS floor tells you nothing about blast radius when the flaw sits at a trust boundary that affects every tenant uniformly.

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