The vulnerability in Glances before version 4.5.6 centers on a function called as_dict_secure() that exposes sensitive credentials through unauthenticated API endpoints. The critical detail is what the function actually does: it filters configuration option names but performs no sanitization on the values themselves. This means credentials embedded anywhere in the configuration value data—including inside the public_api field—pass through unchanged while superficially looking protected because the option name was filtered.
If you're running Glances, treat this as a credential harvesting vector, not a low-severity information leak. The CVSS score of 5.3 is misleading. Glances is a horizontally privileged monitoring tool that authenticates to every system it watches—databases, cloud APIs, message queues, and infrastructure services. An unauthenticated attacker who queries the /api/3/config or /api/3/plugin/cpu endpoints doesn't just get local system details; they get the keys to everything Glances monitors. One exposed AWS credential profile from this endpoint gives an attacker access that pivots outward into infrastructure you don't own, not just lateral movement within your network.
The function name as_dict_secure() is the real warning sign here. The 'secure' suffix created a mental model bypass—it signaled to developers that security was handled, so subsequent code using this function assumed the values were safe without verification. This is a documented pattern in monitoring tools: SNMP monitors, Prometheus endpoints, and Grafana instances have all suffered similar exposures where "admin-only" assumptions collapsed when the tool was network-accessible. The fix in 4.5.6 closed the specific exposed option names, but the architectural question remains whether the underlying value-inspection flaw persists under a different surface. If the patch was surgical—adding targeted exclusions rather than redesigning how values are handled—the underlying assumption that "filtering option names equals secure" remains baked into the codebase, waiting for the next configuration option to bypass the filter.
Check your Glances deployment now: verify the API is not exposed to unauthenticated network access, review what credentials exist in your Glances configuration files, and rotate any credentials that were potentially readable through the pre-4.5.6 API endpoints. The patch timeline matters less than the exposure window—if this instance was reachable, assume the credentials are compromised and act accordingly.