CVE-2026-32633 is a critical-severity security vulnerability in Glances (pip), affecting versions <= 4.5.2-dev01. It is fixed in 4.5.2.
Summary In Central Browser mode, the /api/4/serverslist endpoint returns raw server objects from GlancesServersList.getserverslist(). Those objects are mutated in-place during background polling and can contain a uri field with embedded HTTP Basic credentials for downstream Glances servers, using the reusable pbkdf2-derived Glances authentication secret. If the front Glances Browser/API instance is started without --password, which is supported and common for internal network deployments, /api/4/serverslist is completely unauthenticated. Any network user who can reach the Browser API can retrieve reusable credentials for protected downstream Glances servers once they have been polled by the browser instance. Details The Browser API route simply returns the raw servers list: The main API router is only protected when the front instance itself was started with --password. Otherwise there are no authentication dependencies at all: The Glances web server binds to 0.0.0.0 by default: During Central Browser polling, server entries are modified in-place and gain a uri field: For protected servers, geturi() loads the saved password from the [passwords] section (or the default password), hashes it, and embeds it directly in the URI: Password lookup falls back to a global default: The sample configuration explicitly supports browser-wide default password reuse: The secret embedded in uri is not the cleartext password, but it is still a reusable Glances authentication credential. Client connections send that pbkdf2-derived hash over HTTP Basic authentication: The Browser WebUI also consumes that raw uri directly and redirects the user to it: So once server.uri contains credentials, those credentials are not just used internally; they are exposed to API consumers and frontend JavaScript. PoC Step 1: Verified local live proof that server objects contain credential-bearing URIs The following command executes the real glances/serverslist.py update logic against a live local HTTP server that always returns 401. This forces Glances to mark the downstream server as PROTECTED and then retry with the saved/default password. After the second refresh, the in-memory server list contains a uri field with embedded credentials. Verified output: This is the same raw object shape that /api/4/serverslist returns. Step 2: Remote reproduction on a live Browser instance Configure Glances Browser mode with a saved default password for downstream servers: Start the Browser/API instance without front-end authentication: Ensure at least one protected downstream server is polled and marked PROTECTED. From any machine that can reach the Glances Browser API, fetch the raw server list: Observe entries like: Impact Unauthenticated credential disclosure: When the front Browser API runs without --password, any reachable user can retrieve downstream Glances authentication secrets from /api/4/serverslist. Credential replay: The disclosed pbkdf2-derived hash is the effective Glances client secret and can be replayed against downstream Glances servers using the same password. Fleet-wide blast radius: A single Browser instance can hold passwords for many downstream servers via host-specific entries or [passwords] default, so one exposed API can disclose credentials for an entire monitored fleet. Chains with the earlier CORS issue: Even when the front instance uses --password, the permissive default CORS behavior can let a malicious website read /api/4/serverslist from an authenticated browser session and steal the same downstream credentials cross-origin. Recommended Fix Do not expose credential-bearing fields in API responses. At minimum, strip uri, password, and any derived credential material from /api/4/serverslist responses and make the frontend derive navigation targets without embedded auth. And in the Browser WebUI, construct navigation URLs from non-secret fields (ip, name, port, protocol) instead of trusting a backend-supplied server.uri.
CVE-2026-32633 has a CVSS score of 9.1 (Critical). The vector is network-reachable, 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-dev01)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-32633 is reachable in your applications. Explore open-source security for your team.
See if CVE-2026-32633 is reachable in your applications. Get a demo
Already deployed Kodem? See CVE-2026-32633 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-32633 is a critical-severity security vulnerability in Glances (pip), affecting versions <= 4.5.2-dev01. It is fixed in 4.5.2.
CVE-2026-32633 has a CVSS score of 9.1 (Critical). 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-dev01 is affected.
Yes. CVE-2026-32633 is fixed in 4.5.2. Upgrade to this version or later.
Whether CVE-2026-32633 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.