CVE-2026-73269 is a cluster-admin privilege escalation in the cluster-curator-controller, but the interesting part isn't the privilege escalation — it's how it's triggered. The controller creates cluster-scoped ClusterRoleBindings based on the name of ClusterCurator resources you submit. The naming convention itself acts as the trigger, and there's no admission control between your input and the controller's cluster-admin operations.
This is a category error, not a conventional RBAC misconfiguration. The controller is using resource metadata as an access control boundary, which is a pattern that has appeared in CVE-2021-25741, CVE-2022-2917, and now this — a lineage that suggests this isn't random developer oversight but a systematic failure to treat controller input as untrusted. The naming convention doesn't function as security; it functions as an obscure trigger that any local user can discover by enumerating ClusterCurator resources and watching what ClusterRoleBindings the controller creates in response. There's no cryptographic barrier, no complex precondition chain. You just observe the behavior and replicate the pattern.
The low EPSS score likely reflects that nobody has fuzzed this controller pattern yet, not that exploitation is unlikely. The discovery threshold is trivially low — you don't need internal knowledge, just standard API exploration. If this controller shares a runtime or service account with other controllers — common in operator-heavy distributions — the escalation becomes a pivot point into the broader control plane.
For your response: enumerate ClusterCurator resources in any cluster running this controller and audit what ClusterRoleBindings exist. If the controller is creating bindings you didn't explicitly configure, that's exploitation. More broadly, audit your privileged controllers for name-based or metadata-based gating — regex matches on resource names, startsWith checks, label selectors that control escalation. These are the fingerprints of the same anti-pattern. The CVSS 9.9 is technically accurate, but it obscures the real question: this naming trigger is evidence that the controller's privilege model was never scoped correctly, which means the attack surface likely extends beyond this single trigger.