CVE-2026-32632: 
Python vulnerability analysis and mitigation

CVE-2026-32632 is a DNS rebinding vulnerability in the Glances open-source system monitoring tool, where the main REST/WebUI FastAPI application fails to validate HTTP Host headers, leaving it exposed to DNS rebinding attacks. All versions of Glances prior to 4.5.2 are affected. The vulnerability was published by the project maintainer on March 14, 2026, and added to the National Vulnerability Database on March 18, 2026. It carries a CVSS v3.1 base score of 5.9 (Medium) (GitHub Advisory, Red Hat Bugzilla).

The root cause is an Origin Validation Error (CWE-346): the main FastAPI application in glances/outputs/glances_restful_api.py is initialized without TrustedHostMiddleware or any equivalent host allowlist, while the MCP endpoint already implements such protection. Combined with Glances' default bind address of 0.0.0.0, an attacker can perform a classic DNS rebinding attack — first serving malicious JavaScript from an attacker-controlled domain, then rebinding that domain's DNS to the victim's local Glances IP. The victim's browser then treats the attacker's domain as same-origin with the Glances service, bypassing the browser's same-origin policy entirely without requiring CORS exploitation. The JWT token endpoint (/api/4/token) is mounted on the same unprotected FastAPI app and is equally reachable through the rebinding path (GitHub Advisory).

Successful exploitation allows an unauthenticated remote attacker to read data from Glances REST API endpoints that were intended to be accessible only from local or internal networks, including system configuration, arguments, server lists, and JWT tokens. On deployments without password protection (a common configuration), endpoints such as GET /api/4/all, GET /api/4/config, and GET /api/4/args are fully readable. The vulnerability also serves as a high-value chaining surface, expanding the exploitability of other Glances issues involving permissive CORS, credential-bearing API responses, and state-changing authenticated endpoints. There is no direct availability impact, but confidentiality is highly impacted and integrity is marginally affected (GitHub Advisory).

A proof-of-concept exploit is publicly documented in the official security advisory, including specific HTTP endpoints and a concrete DNS rebinding attack sequence with a fetch() payload targeting a live Glances deployment (GitHub Advisory). There is no evidence of in-the-wild exploitation at this time, and no threat actor attribution has been reported. The EPSS score is approximately 0.015% (0.000150), indicating a low current probability of exploitation in the wild. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Exploitation requires user interaction (victim must visit an attacker-controlled page) and high attack complexity due to the DNS rebinding setup required.

1. Reconnaissance: Identify a target running Glances in web server mode (glances -w) on the victim's local or internal network, typically listening on port 61208 with default bind address 0.0.0.0.
2. Set up attacker infrastructure: Register an attacker-controlled domain (e.g., attacker.example) and configure a DNS server that initially resolves it to the attacker's own IP, with a very short TTL (e.g., 1 second).
3. Serve malicious JavaScript: Host a web page at http://attacker.example that contains JavaScript designed to make API requests to http://attacker.example:61208/api/4/....
4. Lure the victim: Trick a user on the target network into visiting http://attacker.example (e.g., via phishing or a malicious link).
5. Perform DNS rebind: After the victim's browser caches the initial DNS response, update the attacker's DNS to resolve attacker.example to the victim-local Glances IP address (e.g., 192.168.1.x).
6. Exploit same-origin bypass: Once the DNS TTL expires and the browser re-resolves attacker.example to the Glances IP, the attacker's JavaScript issues same-origin requests such as fetch("http://attacker.example:61208/api/4/status"). Because Glances does not validate the Host header, it serves the response.
7. Exfiltrate data: The attacker's JavaScript reads the API response (e.g., system info, config, JWT tokens) and exfiltrates it to the attacker's server. On password-enabled deployments, the JWT token endpoint can also be targeted to enable further authenticated API access (GitHub Advisory).

• Network: Outbound HTTP requests from a victim browser to attacker.example on port 61208 (or the configured Glances port); DNS queries for an external domain resolving to an internal/RFC1918 IP address (DNS rebinding indicator); unexpected cross-origin or same-origin API requests to Glances endpoints from browser user agents.
• Logs: Glances access logs showing requests to /api/4/status, /api/4/all, /api/4/config, /api/4/args, /api/4/serverslist, or /api/4/token with a Host header containing an external or unexpected domain name rather than localhost or the server's configured hostname.
• File System: No direct file system artifacts are expected from read-only API exploitation; however, if chained with authenticated endpoints, look for unexpected configuration changes or new scheduled tasks.
• Process: No unusual child processes are expected from this vulnerability alone, as it is a data-read attack rather than code execution (GitHub Advisory).

Upgrade Glances to version 4.5.2 or later, which applies TrustedHostMiddleware to the main REST/WebUI FastAPI application, rejecting requests whose Host header does not match localhost or 127.0.0.1 by default (Glances v4.5.2 Release). Users accessing Glances through a reverse proxy, custom hostname, or non-loopback IP must declare allowed values using the new webui_allowed_hosts key in the [outputs] section of glances.conf (comma-separated list, wildcards supported). As an interim workaround prior to patching, restrict network access to the Glances port (default 61208) to trusted clients only using firewall rules, and avoid exposing Glances directly to the internet. Reverse-proxy deployments should enforce strict Host header validation at the proxy layer (GitHub Commit).

Red Hat tracked the vulnerability via their security response process and opened a Bugzilla entry (Bug 2448708) with medium severity, indicating it affects packages in their ecosystem (Red Hat Bugzilla). The Glances v4.5.2 release notes acknowledge the reporter (offset) and note that this was one of eight security vulnerabilities addressed simultaneously, suggesting a coordinated disclosure effort (Glances v4.5.2 Release). No significant broader media coverage or notable social media discussion has been identified beyond standard vulnerability database aggregators.