Glances

CVE-2026-32632

CVE-2026-32632 is a medium-severity security vulnerability in Glances (pip), affecting versions < 4.5.2. It is fixed in 4.5.2.

Key facts
CVSS score
5.9
Medium
Attack vector
Network
Issuing authority
GitHub Advisory Database
Affected package
Glances
Fixed in
4.5.2
Disclosed
2026

Summary

Summary Glances recently added DNS rebinding protection for the MCP endpoint, but the main REST/WebUI FastAPI application still accepts arbitrary Host headers and does not apply TrustedHostMiddleware or an equivalent host allowlist. As a result, the REST API, WebUI, and token endpoint remain reachable through attacker-controlled domains in classic DNS rebinding scenarios. Once the victim browser has rebound the attacker domain to the Glances service, same-origin policy no longer protects the API because the browser considers the rebinding domain to be the origin. This is a distinct issue from the previously reported default CORS weakness. CORS is not required for exploitation here because DNS rebinding causes the victim browser to treat the malicious domain as same-origin with the rebinding target. Details The MCP endpoint now has explicit host-based transport security: However, the main FastAPI application for REST/WebUI/token routes is initialized without any host validation middleware: There is no TrustedHostMiddleware, no comparison against the configured bind host, and no allowlist enforcement for HTTP Host values on the REST/WebUI surface. The default bind configuration also exposes the service on all interfaces: This combination means the HTTP service will typically be reachable from the victim machine under an attacker-selected hostname once DNS is rebound to the Glances listener. The token endpoint is also mounted on the same unprotected FastAPI app: Why This Is Exploitable In a DNS rebinding attack: The attacker serves JavaScript from https://attacker.example. The victim visits that page while a Glances instance is reachable on the victim network. The attacker's DNS for attacker.example is rebound from the attacker's server to the Glances IP address. The victim browser now sends same-origin requests to https://attacker.example, but those requests are delivered to Glances. Because the Glances REST/WebUI app does not validate the Host header or enforce an allowed-host policy, it serves the response. The attacker-controlled JavaScript can read the response as same-origin content. The MCP code already acknowledges this threat model and implements host-level defenses. The REST/WebUI code path does not. Proof of Concept This issue is code-validated by inspection of the current implementation: REST/WebUI/token are all mounted on a plain FastAPI(...) app no TrustedHostMiddleware or equivalent host validation is applied default bind is 0.0.0.0 MCP has separate rebinding protection, showing the project already recognizes the threat model In a live deployment, the expected verification is: And if the operator exposes Glances without --password (supported and common), the attacker can read endpoints such as: Even on password-enabled deployments, the missing host validation still leaves the REST/WebUI/token surface reachable through rebinding and increases the value of chains with other authenticated browser issues. Impact Remote read of local/internal REST data: DNS rebinding can expose Glances instances that were intended to be reachable only from a local or internal network context. Bypass of origin-based browser isolation: Same-origin policy no longer protects the API once the browser accepts the attacker-controlled rebinding host as the origin. High-value chaining surface: This expands the exploitability of previously identified Glances issues involving permissive CORS, credential-bearing API responses, and state-changing authenticated endpoints. Token surface exposure: The JWT token route is mounted on the same host-unvalidated app and is therefore also reachable through the rebinding path. Recommended Fix Apply host allowlist enforcement to the main REST/WebUI FastAPI app, similar in spirit to the MCP hardening: At minimum: reject requests whose Host header does not match an explicit allowlist do not rely on 0.0.0.0 bind semantics as an access-control boundary document that reverse-proxy deployments must set a strict host allowlist References glances/outputs/glancesmcp.py glances/outputs/glancesrestful_api.py glances/main.py

Impact

Severity and exposure

CVE-2026-32632 has a CVSS score of 5.9 (Medium). The vector is network-reachable, no privileges required, and user interaction required. 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.

Affected versions

pip

  • Glances (< 4.5.2)

Security releases

  • Glances → 4.5.2 (pip)
Kodem intelligence

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-32632 is reachable in your applications. Explore open-source security for your team.

See if CVE-2026-32632 is reachable in your applications. Get a demo

Already deployed Kodem? See CVE-2026-32632 in your environment

Remediation advice

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.

Frequently asked questions about CVE-2026-32632

What is CVE-2026-32632?

CVE-2026-32632 is a medium-severity security vulnerability in Glances (pip), affecting versions < 4.5.2. It is fixed in 4.5.2.

How severe is CVE-2026-32632?

CVE-2026-32632 has a CVSS score of 5.9 (Medium). 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.

Which versions of Glances are affected by CVE-2026-32632?

Glances (pip) versions < 4.5.2 is affected.

Is there a fix for CVE-2026-32632?

Yes. CVE-2026-32632 is fixed in 4.5.2. Upgrade to this version or later.

Is CVE-2026-32632 exploitable, and should I be worried?

Whether CVE-2026-32632 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

What actually determines whether CVE-2026-32632 is exploitable, and how bad it is?

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.

How do I fix CVE-2026-32632?

Upgrade Glances to 4.5.2 or later.

Stop the waste.
Protect your environment with Kodem.