The nil pointer dereference in private_registry.go is a red herring. What you actually have is a temporal ordering failure: the code retrieves the cluster object before validating the requester's token. When the token validation fails, the response differs depending on whether the cluster has private registry secrets configured — a 502 crash versus a 200 with YAML. That's the oracle. An attacker can enumerate cluster IDs and learn not just that a cluster exists, but whether it has private registry secrets configured. That's infrastructure topology information that enables targeted credential theft follow-ons.
The immediate fix is to validate the token before touching the cluster object. This isn't a nil check problem — it's an authentication ordering problem. If your codebase has other endpoints where resource retrieval precedes token validation, they likely have the same oracle condition; the difference is those paths handle errors gracefully so the differential isn't visible. The nil pointer dereference is actually the only reason this CVE exists — it's the detection mechanism that made the underlying broken pattern discoverable.
As a secondary control, standardizing error responses (returning identical HTTP status codes regardless of whether the cluster exists or has private registry secrets) would close the oracle even if ordering issues persist elsewhere. But this is a surface patch, not a structural fix. The pattern of authentication-after-access suggests this may be a codebase-level issue rather than an isolated mistake — audit other endpoints for similar ordering failures. The fix should be at the framework level: your auth layer should enforce that resource access cannot occur before validation, otherwise this pattern will recur in future endpoints.