CVE-2026-18378

This CVE exposes a structural flaw in how operator permissions map to secret access. The CostManagementMetricsConfig CustomResource has a user-configurable URL field for metrics uploads. When you grant 'edit' permissions on this CR, you've effectively granted the ability to redirect a cluster-global Red Hat Cloud bearer token to any destination. The operator correctly attaches this token because that's its job — the vulnerability is that the destination was never validated as trusted configuration. Standard RBAC audits will miss this. 'Edit' on a CustomResource looks scoped and low-risk. But when that CR's fields control where operator-attached secrets are transmitted, you've crossed a trust boundary that conventional permission analysis doesn't model. An attacker with 'edit' on this CR need only specify a URL they control and wait for the operator's next sync cycle — the token arrives on a schedule without further action required. Check your environment: identify any CustomResources that allow configuring destinations (URLs, endpoints, storage locations) while the operator simultaneously attaches cluster-global credentials to those same operations. If your RBAC analysis treats CR-level permissions as inherently lower-risk than secret access, this CVE demonstrates that assumption is false — the permission-to-impact gap is invisible until you trace the complete data flow from CR field through operator logic to credential attachment. This pattern — user-controllable destination + operator-attached credentials — has historical roots in SSRF and CI/CD supply chain vulnerabilities. The operator ecosystem simply hadn't mapped these known failure modes to CRD trust boundaries. Beyond patching this specific operator, audit for equivalent patterns in other operators: any CR that lets users specify where credentials go is a potential privilege escalation vector regardless of how limited the CR permission appears.

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