Bug 2509251 (CVE-2026-18381)
| Summary: | CVE-2026-18381 project-koku/koku-metrics-operator: koku-metrics-operator: operator service-account token exfiltration via user-controlled Prometheus service_address | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | OSIDB Bzimport <bzimport> |
| Component: | vulnerability | Assignee: | Product Security <prodsec-ir-bot> |
| Status: | NEW --- | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | unspecified | CC: | cmyers, dnakabaa, kaycoth, lcouzens |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | --- | |
| Doc Text: |
A flaw was found in the koku-metrics-operator for Red Hat OpenShift. The operator's CostManagementMetricsConfig custom resource allows a user able to edit the CR to specify an arbitrary upload URL. The operator attaches its own Kubernetes service-account bearer token to queries sent to this user-controlled URL, allowing the attacker to obtain the token.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | --- | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
## Summary The koku-metrics-operator CostManagementMetricsConfig CRD exposes `spec.prometheus_config.service_address` as a free-form string with no host validation. The operator reads its own Kubernetes service-account token from `/var/run/secrets/kubernetes.io/serviceaccount/token` and configures it as the `BearerToken` for PromQL queries sent to this user-supplied address. The service-account token carries the `manager-role` ClusterRole, which grants `get` on all Secrets cluster-wide. ## Impact A principal with `create`/`update` permission on `costmanagementmetricsconfigs` in the operator namespace can harvest the operator's Kubernetes service-account token by redirecting Prometheus queries to an attacker-controlled endpoint. This token grants read access to every named Secret in any namespace across the cluster. ## Affected Code - `api/v1beta1/metricsconfig_types.go:198` — `service_address` field definition (no validation) - `internal/collector/prometheus.go:95-117` — token read and client configuration - `config/rbac/role.yaml:18-22` — ClusterRole grants `secrets:get` cluster-wide ## Remediation Restrict `service_address` to in-cluster Prometheus/Thanos endpoints via CRD CEL validation: ```yaml x-kubernetes-validations: - rule: "url(self.service_address).getHostname().endsWith('.openshift-monitoring.svc') || url(self.service_address).getHostname().endsWith('.openshift-monitoring.svc.cluster.local')" message: "service_address must target the in-cluster monitoring service" ``` Or use a `TokenRequest` API call with audience bound to `prometheus-k8s` so the token is not replayable against `kube-apiserver`.