CVE-2026-32634 is a high-severity security vulnerability in Glances (pip), affecting versions < 4.5.2. It is fixed in 4.5.2.
Summary 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. Details Dynamic server discovery keeps both a short name and a separate ip: The Zeroconf listener populates those fields directly from the service advertisement: However, the Central Browser connection logic ignores server['ip'] and instead uses the untrusted advertised server['name'] for both password lookup and the destination URI: That URI is used automatically by the background polling thread: The password lookup itself falls back to the global default password when there is no exact match: The sample configuration explicitly supports that default credential reuse: The secret sent over the network is not the cleartext password, but it is still a reusable Glances authentication credential. The client hashes the configured password and sends that hash over HTTP Basic authentication: There is an inconsistent trust boundary in the interactive browser code as well: glances/clientbrowser.py:44 opens the REST/WebUI target via webbrowser.open(self.serverslist.geturi(server)), which again trusts server['name'] glances/clientbrowser.py:55 fetches saved passwords with self.serverslist.password.getpassword(server['name']) glances/clientbrowser.py:76 uses server['ip'] for the RPC client connection That asymmetry shows the intended safe destination (ip) is already available, but the credential-bearing URI and password binding still use the attacker-controlled Zeroconf name. Exploit Flow The victim runs Glances in Central Browser mode with autodiscovery enabled and has a saved Glances password in [passwords] (especially default=...). An attacker on the same multicast domain advertises a fake glances.tcp.local. service with an attacker-controlled service name. Glances stores the discovered server as {'name': <advertised-name>, 'ip': <discovered-ip>, ...}. The background stats refresh calls geturi(server). Once the fake server causes the entry to become PROTECTED, geturi() looks up a saved password by the attacker-controlled name, falls back to default if present, hashes it, and builds http://username:hash@<advertised-name>:<port>. The attacker receives a reusable Glances authentication secret and can replay it against Glances servers using the same credential. PoC Step 1: Verified local logic proof The following command executes the real glances/serverslist.py geturi() implementation (with unrelated imports stubbed out) and demonstrates that: password lookup happens against server['name'], not server['ip'] the generated credential-bearing URI uses server['name'], not server['ip'] Verified output: This confirms the code path binds credentials to the advertised name and ignores the discovered ip. Step 2: Live network reproduction Configure a reusable browser password: Start Glances in Central Browser mode on the victim machine: On an attacker-controlled machine on the same LAN, advertise a fake Glances Zeroconf service and return HTTP 401 / XML-RPC auth failures so the entry becomes PROTECTED: On the next Central Browser refresh, Glances first probes the fake server, marks it PROTECTED, then retries with: The attacker captures the Basic-auth credential and can replay that value as the Glances password hash against Glances servers that share the same configured password. Impact Credential exfiltration from browser operators: An adjacent-network attacker can harvest the reusable Glances authentication secret from operators running Central Browser mode with saved passwords. Authentication replay: The captured pbkdf2-derived Glances password hash can be replayed against Glances servers that use the same credential. REST/WebUI click-through abuse: For REST servers, webbrowser.open(self.serverslist.geturi(server)) can open attacker-controlled URLs with embedded credentials. No user click required for background theft: The stats refresh thread uses the vulnerable path automatically once the fake service is marked PROTECTED. Affected scope: This is limited to Central Browser deployments with autodiscovery enabled and saved/default passwords configured. Static server entries and standalone non-browser use are not directly affected by this specific issue. Recommended Fix Use the discovered ip as the only network destination for autodiscovered servers, and do not automatically apply saved or default passwords to dynamic entries. And use the same getpreconfiguredpassword() logic in glances/clientbrowser.py instead of calling self.serverslist.password.get_password(server['name']) directly.
CVE-2026-32634 has a CVSS score of 8.1 (High). The vector is reachable from an adjacent network, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment.
A fixed version is available (4.5.2). Upgrading removes the vulnerable code path.
pip
Glances (< 4.5.2)Glances → 4.5.2 (pip)Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter instead of chasing every advisory.
Kodem's runtime-powered SCA identifies whether CVE-2026-32634 is reachable in your applications. Explore open-source security for your team.
See if CVE-2026-32634 is reachable in your applications. Get a demo
Already deployed Kodem? See CVE-2026-32634 in your environment →Upgrade Glances to 4.5.2 or later to resolve this vulnerability.
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
CVE-2026-32634 is a high-severity security vulnerability in Glances (pip), affecting versions < 4.5.2. It is fixed in 4.5.2.
CVE-2026-32634 has a CVSS score of 8.1 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
Glances (pip) versions < 4.5.2 is affected.
Yes. CVE-2026-32634 is fixed in 4.5.2. Upgrade to this version or later.
Whether CVE-2026-32634 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
Upgrade Glances to 4.5.2 or later.