CVE-2026-46607: Glances Unsafe Pickle Deserialization Remote Code Execution

Technical summary

Glances versions prior to 4.5.5 contain an unsafe deserialization vulnerability in glances/outdated.py. The code invokes pickle.load() on a cache file located at ~/.cache/glances/glances-version.db (or $XDG_CACHE_HOME equivalent) without any integrity checks, cryptographic verification, or schema validation. The cache file path is predictable and often world-writable in multi-user or container environments. An attacker with local filesystem write access can place a crafted pickle object at this location. On the next invocation of Glances with version-check functionality enabled—the default configuration—the deserialization process executes embedded bytecode within the malicious pickle, yielding arbitrary code execution under the privileges of the Glances process owner. This is a classic unsafe deserialization vulnerability (CWE-502).

Business impact

Organizations deploying Glances for infrastructure monitoring face a straightforward privilege-escalation vector. In containerized environments (Docker, Kubernetes), a compromised application or sidecar can poison the version cache to escalate from app user to host or cluster access if Glances runs with elevated privileges. On shared multi-user systems, any lower-privileged user can corrupt the cache to compromise higher-privileged monitoring jobs. Cloud platforms and CI/CD pipelines using Glances for diagnostics become potential pivot points. The default-enabled version checking means most installations are at risk unless explicitly disabled.

Affected systems

Glances versions before 4.5.5 are vulnerable. The threat surface includes: any Linux, macOS, or Windows system running Glances for local or remote monitoring; containerized workloads using Glances as a monitoring or diagnostic tool; shared hosting or multi-tenant environments; CI/CD pipelines that invoke Glances during build or test phases. Systems where version checking has been manually disabled are not vulnerable to this specific attack path. Verify your installed version with 'glances --version'; upgrades to 4.5.5 or later eliminate the risk.

Exploitability

Exploitability is practical and local in scope. The attacker must have write access to the cache directory, which is typically achievable through: container escape or misconfiguration; local user compromise; shared filesystem vulnerabilities; temporary file race conditions; or overly permissive directory ownership. No network traversal, authentication bypass, or complex user interaction is required. Once the malicious pickle is in place, exploitation is automatic and reliable on the next Glances invocation. The default-enabled version checking ensures that most instances will attempt deserialization without additional user action.

Remediation

The immediate fix is to upgrade Glances to version 4.5.5 or later, which eliminates the unsafe deserialization. As a short-term mitigation, users can disable version checking (typically via configuration flag or environment variable) to prevent the vulnerable code path from executing, though this forgoes the version-check feature. In high-security environments, restrict filesystem permissions on ~/.cache/glances to prevent unauthorized writes. Monitor for signs of cache directory tampering or unexpected process spawning from Glances invocations.

Patch guidance

Upgrade Glances to version 4.5.5 or later. The fix removes the unsafe pickle.load() call and replaces it with safer deserialization or removes the caching mechanism entirely; consult the official Glances release notes for the exact implementation. Package managers (pip, apt, brew, etc.) should all have the patched version available shortly after publication. In containerized deployments, rebuild and redeploy images with the new version. For systems unable to patch immediately, disable the version-check feature via configuration to close the exploitation vector.

Detection guidance

Look for unexpected child processes spawned from Glances or unusual system commands executed under the Glances user's context, especially on startup. Monitor filesystem access to ~/.cache/glances/glances-version.db for modifications by unexpected accounts. Audit file permissions on the cache directory for overly broad write access. In container orchestration, check for Glances pods restarting or exhibiting abnormal behavior after cache directory modifications. Review process execution logs around Glances startup events for anomalous commands. Integrity monitoring on the cache file itself (e.g., via inotify or auditd) can catch tampering in real time.

Why prioritize this

This vulnerability merits immediate attention due to its combination of high CVSS impact (7.8), default-enabled exploitation pathway, and ease of triggering. In containerized and multi-user environments, write-access to the cache directory is often trivial to obtain, making the gap between discovery and reliable code execution very small. The arbitrary code execution capability and low complexity of the attack justify prioritizing patching ahead of many other vulnerabilities. Organizations running Glances in production monitoring roles should treat this as critical.

Risk score, explained

The CVSS 3.1 score of 7.8 (HIGH) reflects: local attack vector (AV:L) appropriate to the cache-file mechanism; low attack complexity (AC:L) because no special conditions or race conditions are needed; low privileges required (PR:L) indicating a standard local user can mount the attack; no user interaction (UI:N) because exploitation is automatic; and confidentiality, integrity, and availability all set to high (C:H/I:H/A:H) reflecting complete code execution. The score does not account for the default-enabled configuration and ease of cache-directory compromise in many real-world deployments, so actual organizational risk may be higher.

Frequently asked questions