CVE-2026-71846

CVE-2026-71846 exposes a ServiceAccount with cluster-wide read access to all Secrets, but the real vulnerability isn't the over-privileged identity—it's that your deployment pipeline shipped and maintained permissions disconnected from what the code actually requires. The insights-client only needs one specific Secret, yet the ClusterRoleBinding grants get/list/watch on every Secret in the cluster. Nothing in your deployment workflow caught this mismatch. The low EPSS score (0.00116) should not comfort you. EPSS measures exploitability given current access, not severity if that access is compromised. This isn't a flat blast radius—cluster-wide secrets read here exposes the managed-cluster kubeconfigs, the credential store for every federated cluster. Compromise of insights-client doesn't yield one cluster's secrets; it yields the keys to your entire cluster federation. That's a topology failure, not just a permission escalation. The concerning pattern: over-privileged service accounts are evolutionarily stable in Kubernetes precisely because they never trigger errors. They pass every CI gate, every test, every health check. They persist indefinitely because the system never signals that they're excessive. The fix isn't just narrowing the ClusterRole to the single Secret insights-client actually needs—it's auditing whether that over-provisioning was ever justified or always an error, and actively removing the ghost ClusterRole that will persist in version control, helm templates, and rollback configurations after the fix ships. The question to argue isn't the CVSS score. It's whether your organization has any mechanism to enforce that RBAC permissions match actual code requirements—and whether the disclosure of this CVE creates an acceleration window where attackers now have a roadmap to enumerate permissions that previously required discovery.

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