CVE-2026-71845

The CVSS 6.3 score on this CVE badly misrepresents the actual risk profile, and the reason cuts to how CVSS models threat scenarios that don't fit its assumptions. The vulnerability: insights-client logs all environment variables at verbosity level 2 through a setDefault() call, exposing the CCX_TOKEN credential that manages the disconnected cluster itself. The CVSS framing treats this as generic credential exposure in logs—a well-understood, medium-severity finding. But two factors change the risk calculus fundamentally. First, the token scope. This isn't a SaaS API key for a single integration—it's a cluster management credential. If CCX_TOKEN permits pushing configurations, enumerating managed fleets, or accessing sensitive cluster metadata, the blast radius extends beyond the compromised cluster to every cluster sharing that logging infrastructure. The CVSS base score has no vocabulary for management-plane credentials that have already been exfiltrated by design. Second, and more critically: the attack requires zero attacker action. The CVE assumes an adversary must somehow obtain the logs. But in environments with centralized logging—and centralized logging is standard practice precisely because disconnected clusters generate log volumes that make per-node inspection impractical—the credential has already been delivered to wherever the logs reside. Read the SIEM, find the token, hit the API. No spear-phishing, no zero-day, no lateral movement. The exploitability dimension of CVSS assumes the attacker has to work for access; here, access is already granted through normal operational tooling. The deeper issue is that 'disconnected deployment' was treated as a security boundary when it only addresses network egress. The information-flow side—logging, debug output, crash dumps—consistently gets classified as an operational concern rather than a security boundary. That's the assumption this CVE should force you to examine: what explicit threat model covers log destination assumptions for disconnected clusters, and who owns that analysis when the product team treats 'disconnected' as a deployment topology rather than a security context? What to do: audit your centralized logging pipeline for CCX_TOKEN exposure, determine whether that token scope extends beyond insights telemetry to cluster management operations, and treat any centralized logging from disconnected clusters as a potential information-flow boundary that requires explicit threat modeling.

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