CVE-2026-32634 in glances
Summary
by MITRE • 03/18/2026
Glances is an open-source system cross-platform monitoring tool. Prior to version 4.5.2, in Central Browser mode, Glances stores both the Zeroconf-advertised server name and the discovered IP address for dynamic servers, but later builds connection URIs from the untrusted advertised name instead of the discovered IP. When a dynamic server reports itself as protected, Glances also uses that same untrusted name as the lookup key for saved passwords and the global `[passwords] default` credential. An attacker on the same local network can advertise a fake Glances service over Zeroconf and cause the browser to automatically send a reusable Glances authentication secret to an attacker-controlled host. This affects the background polling path and the REST/WebUI click-through path in Central Browser mode. Version 4.5.2 fixes the issue.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 03/24/2026
The vulnerability CVE-2026-32634 resides within the Glances monitoring tool's Central Browser mode implementation, representing a critical authentication bypass and credential exposure flaw that affects systems running versions prior to 4.5.2. This vulnerability stems from improper handling of Zeroconf service advertisements and demonstrates a classic case of insecure credential storage and retrieval mechanisms that can be exploited through network-level attacks. The flaw specifically impacts how Glances processes dynamic server information, creating a pathway for attackers to manipulate the authentication flow through malicious service discovery.
The technical implementation of this vulnerability involves a fundamental flaw in the credential management and connection establishment processes within Glances. When Glances operates in Central Browser mode, it discovers servers through Zeroconf advertisements and stores both the advertised server name and the discovered IP address. However, the application subsequently constructs connection URIs using the untrusted advertised name rather than the verified IP address, creating a potential attack vector. The vulnerability becomes particularly dangerous when dynamic servers report themselves as protected, as Glances then uses the same untrusted advertised name for both credential lookup and connection establishment, effectively creating a credential exposure scenario where attacker-controlled names can be used to retrieve and exploit stored authentication secrets.
The operational impact of this vulnerability extends across multiple attack vectors within the Glances ecosystem, affecting both background polling mechanisms and the REST/WebUI click-through paths. Attackers can leverage this vulnerability by simply advertising a fake Glances service over the local network through Zeroconf, causing the legitimate Glances browser to automatically establish connections to attacker-controlled hosts using stored credentials. This creates a persistent threat where authentication secrets can be harvested and reused across multiple sessions, potentially compromising access to monitored systems. The vulnerability affects the core authentication flow of the application and can be exploited without requiring any special privileges or authentication from the attacker beyond network access.
This vulnerability aligns with several established cybersecurity frameworks and threat models, particularly mapping to CWE-287 which addresses improper authentication and CWE-352 which covers cross-site request forgery. The attack pattern follows ATT&CK technique T1566 for credential harvesting and T1071 for application layer protocol usage. The flaw demonstrates poor input validation and trust assumptions in network service discovery, where the application blindly trusts information provided through Zeroconf advertisements without proper verification. The vulnerability represents a significant weakness in the application's security architecture, particularly in its handling of dynamic service discovery and credential management. The fix implemented in version 4.5.2 addresses the core issue by ensuring that connection URIs are constructed using verified IP addresses rather than potentially malicious advertised names, thereby preventing the exploitation pathway that allowed credential exposure through malicious service advertisements.
The remediation approach taken by the Glances development team focuses on strengthening the trust model used during service discovery and connection establishment. By ensuring that connection URIs are built from verified IP addresses rather than untrusted advertised names, the vulnerability is effectively neutralized. This fix also addresses the credential lookup mechanism, ensuring that password retrieval is performed using verified connection information rather than potentially malicious service names. The implementation of this fix demonstrates the importance of proper input validation and the principle of least trust in network applications, particularly those operating in potentially hostile local network environments. Organizations should immediately upgrade to version 4.5.2 or later to mitigate this vulnerability and prevent potential credential exposure through malicious service advertisement attacks.