CVE-2026-32633: 
Python vulnerability analysis and mitigation

CVE-2026-32633 is a critical unauthenticated credential disclosure vulnerability in the Glances system monitoring tool's Central Browser API. When a Glances Browser/API instance is started without the --password flag — a common configuration for internal network deployments — the /api/4/serverslist endpoint is completely unauthenticated and returns raw server objects containing embedded HTTP Basic credentials (pbkdf2-derived hashes) for downstream Glances servers. All versions up to and including 4.5.2-dev01 are affected; the fix is included in version 4.5.2. It carries a CVSS v3.1 base score of 9.1 (Critical) (GitHub Advisory, Red Hat Bugzilla).

The root cause is a combination of CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) and CWE-522 (Insufficiently Protected Credentials). During Central Browser polling, server entries in GlancesServersList are mutated in-place: the get_uri() method loads saved passwords from the [passwords] configuration section, hashes them via PBKDF2, and embeds the resulting hash directly into a uri field formatted as http://username:hash@host:port. The _api_servers_list() route then returns these raw objects without sanitization. Because the API router only applies authentication middleware when the front instance is started with --password, and the web server binds to 0.0.0.0 by default, any network-reachable user can issue a simple GET /api/4/serverslist request to retrieve these credential-bearing URIs. Additionally, even when --password is used, the permissive default CORS policy (Access-Control-Allow-Origin: *) allows a malicious website to read the endpoint cross-origin from an authenticated browser session (GitHub Advisory, Glances Security Advisory).

An unauthenticated attacker with network access to the Glances Browser API can retrieve pbkdf2-derived authentication hashes for all downstream Glances servers managed by that Browser instance. Because these hashes are the effective Glances client secrets — sent directly over HTTP Basic authentication — they can be replayed against downstream servers to gain unauthorized access without cracking. If a single Browser instance is configured with a [passwords] default entry or multiple host-specific entries, a single API call can expose credentials for an entire monitored server fleet, enabling broad lateral movement across the infrastructure. The Browser WebUI also consumed the raw server.uri field directly in JavaScript to redirect users, meaning the credentials were also exposed to frontend code (GitHub Advisory).

A proof-of-concept exploit is publicly available in the official GitHub security advisory, which provides step-by-step reproduction instructions including exact curl commands and configuration setup (Glances Security Advisory). Exploitation requires no authentication, no privileges, and no user interaction — a single HTTP GET request to /api/4/serverslist is sufficient. The EPSS score is approximately 0.13%, and there is no current evidence of in-the-wild exploitation or CISA KEV catalog listing. Qualys has published a detection (ID: 5009226) for this vulnerability.

1. Reconnaissance: Identify internet-facing or internally accessible Glances Browser instances using tools like Shodan, Censys, or network scanning (default port 61208), targeting versions prior to 4.5.2.
2. Verify unauthenticated access: Confirm the Browser API is running without --password by issuing a test request: curl -s http://TARGET:61208/api/4/serverslist. A JSON response (rather than a 401) confirms the endpoint is unauthenticated.
3. Retrieve credential-bearing server list: Parse the JSON response for server entries with status: PROTECTED and a populated uri field, e.g., http://glances:hash(defaultpassword)@internal-glances.example:61209.
4. Extract reusable credential hash: Extract the pbkdf2-derived password hash embedded in the uri field. This hash is the effective Glances client secret used for HTTP Basic authentication.
5. Replay credentials against downstream servers: Use the extracted username and hash to authenticate directly against downstream Glances servers: curl -s http://glances:EXTRACTED_HASH@internal-glances.example:61209/api/4/all, gaining full API access to those monitored systems.
6. CORS-based attack (alternative): If the front instance uses --password, host a malicious webpage that issues a cross-origin fetch('http://TARGET:61208/api/4/serverslist') request, exploiting the permissive default CORS policy to steal credentials from an authenticated victim's browser session (Glances Security Advisory).

• Network: Unexpected or repeated unauthenticated HTTP GET requests to /api/4/serverslist from external or untrusted IP addresses in web server access logs; outbound connections from downstream Glances servers originating from unfamiliar client IPs using valid credentials.
• Logs: Glances web server access logs showing GET /api/4/serverslist requests returning HTTP 200 from non-administrative source IPs; downstream Glances server logs showing successful authenticated API access from unexpected client addresses.
• Application Behavior: Downstream Glances servers reporting authenticated sessions from IP addresses that do not correspond to the known Browser instance; unexpected data queries against monitored server APIs.

Upgrade Glances to version 4.5.2 or later, which strips uri and password fields from /api/4/serverslist API responses via a new _sanitize_server() method, and updates the Browser WebUI to construct navigation URLs from non-secret fields (Glances v4.5.2 Release, Patch Commit). As an immediate workaround, enable the --password flag on all Browser API instances to require authentication for /api/4/serverslist. Additionally, restrict CORS settings to only trusted origins using the new cors_origins key in the [outputs] section of glances.conf, and limit network access to the Glances Browser API port (default 61208) to trusted networks only. Rotate all downstream Glances server credentials that may have been exposed to any untrusted party (Red Hat Bugzilla).

The vulnerability received coverage from The Hacker Wire and was discussed on Reddit's r/pwnhub community, where it was highlighted as a critical credential exposure risk for monitoring infrastructure (The Hacker Wire, Reddit). Red Hat tracked the issue via Bugzilla with an 'urgent' severity rating (Red Hat Bugzilla). The vulnerability was also included in a Loginsoft weekly threat landscape summary noting its significance alongside KEV additions.