insights-client CVE-2026-71845

Two explicit conditions must both be satisfied. First, glog verbosity must be configured at level 2 or higher - this is a non-default debugging setting that must be deliberately enabled, either via a command-line flag or environment variable passed to insights-client; production deployments running at default verbosity (level 0 or 1) are not exposed. Second, the attacker must hold read access to pod logs in the namespace where insights-client runs, either directly via kubectl (requiring the pods/log RBAC permission) or via a centralized log aggregation backend that ingests the pod's stdout. The CCX_TOKEN environment variable must also be populated, which only occurs in disconnected cluster deployment modes. What limits exploitation: the combination of elevated verbosity (non-default) and log-read access substantially narrows the realistic attacker population; the attacker cannot force verbosity changes without higher privileges; and the credential exposed (CCX_TOKEN) provides access only to the CCX API, not broader cluster administrative control.

Multiple signals place this at moderate-to-elevated risk within its target population despite the High CVSS score of 7.7. The CVSS vector AV:N/AC:L/PR:L/UI:N/S:C/C:H accurately captures the credential-theft impact and scope change, but the network attack vector warrants clarification: exploitation is passive log-harvesting rather than active network exploitation, which the vector notation can imply. The S:C scope change is the most consequential signal - a stolen CCX_TOKEN grants API-level access to disconnected cluster management, extending the blast radius well beyond the logging pod itself. Counterbalancing factors: EPSS 0.21% (11th percentile) indicates very low empirical exploitation probability; SSVC rates exploitation as none and automatable as no, consistent with the requirement for pre-existing log infrastructure access (PR:L); the glog verbosity condition (level 2+) is non-default and must be deliberately set, significantly narrowing the vulnerable population. No KEV listing and no POC code identified. This is a genuine risk for ACM operators running debug-verbosity configurations in production, but not a broad internet-scale threat.

An attacker with low-privilege access to an OpenShift cluster - for example, a developer with namespace-scoped kubectl access - runs kubectl logs against the insights-client pod and searches the output for CCX_TOKEN. If the pod was started with glog verbosity at level 2 or higher, the token appears in clear text on every startup. The attacker then uses this bearer token in a direct HTTP request to the CCX API endpoint, gaining unauthorized access to disconnected cluster management data without any further exploitation steps.