GHSA-9jfm-9rc6-2hfq Glances's Default CORS Configuration Allows Cross-Origin Credential Theft
SummaryThe Glances REST API web server ships with a default CORS configuration that sets `allow_origins=["*"]` combined with `allow_credentials=True`. When both of these options are enabled together, Starlette's `CORSMiddleware` reflects the requesting `Origin` header value in the `Access-Control-Allow-Origin` response header instead of returning the literal `*` wildcard. This effectively grants any website the ability to make credentialed cross-origin API requests to the Glances server, enabling cross-site data theft of system monitoring information, configuration secrets, and command line arguments from any user who has an active browser session with a Glances instance.DetailsThe CORS configuration is set up in `glances/outputs/glances_restful_api.py` lines 290-299:The defaults are loaded from the config file, but when no config is provided (which is the common case for most deployments), the defaults are:`cors_origins = ["*"]` (all origins)`cors_credentials = True` (allow credentials)Per the CORS specification, browsers should not send credentials when `Access-Control-Allow-Origin: *`. However, Starlette's `CORSMiddleware` implements a workaround: when `allow_origins=["*"]` and `allow_credentials=True`, the middleware reflects the requesting origin in the response header instead of using `*`. This means:Attacker hosts `https://evil.com/steal.html`Victim (who has authenticated to Glances via browser Basic Auth dialog) visits that pageJavaScript on `evil.com` makes `fetch("http://glances-server:61208/api/4/config", {credentials: "include"})`The browser sends the stored Basic Auth credentialsStarlette responds with `Access-Control-Allow-Origin: https://evil.com` and `Access-Control-Allow-Credentials: true`The browser allows JavaScript to read the responseAttacker exfiltrates the configuration including sensitive dataWhen Glances is running **without** `--password` (the default for most internal network deployments), no authentication is required at all. Any website can directly read all API endpoints including system stats, process lists, configuration, and command line arguments.PoC**Step 1: Attacker hosts a malicious page.****Step 2: Verify CORS headers (without auth, default Glances).****Step 3: Verify data theft (without auth).****Step 4: With authentication enabled, verify CORS still allows cross-origin credentialed requests.**Impact**Without `--password` (default):** Any website visited by a user on the same network can silently read all Glances API endpoints, including complete system monitoring data (process list with command lines, CPU/memory/disk stats, network interfaces and IP addresses, filesystem mounts, Docker container info), configuration file contents (which may contain database passwords, export backend credentials, API keys), and command line arguments.**With `--password`:** If the user has previously authenticated via the browser's Basic Auth dialog (which caches credentials), any website can make cross-origin requests that carry those cached credentials. This allows exfiltration of all the above data plus the password hash itself (via `/api/4/args`).**Network reconnaissance:** An attacker can use this to map internal network infrastructure by having victims visit a page that probes common Glances ports (61208) on internal IPs.**Chained with POST endpoints:** The CORS policy also allows `POST` methods, enabling an attacker to clear event logs (`/api/4/events/clear/all`) or modify process monitoring (`/api/4/processes/extended/{pid}`).Recommended FixChange the default CORS credentials setting to `False`, and when credentials are enabled, require explicit origin configuration instead of wildcard:
CVSS v3.1 score: 8.1