Summary
Glances: REST API CORS Credentials Guard Uses Exact-Match Instead of Membership Test, Bypassed by Any Multi-Origin Allowlist Containing the Wildcard
Glances's REST API server includes a documented safety check intended to guarantee that cors_credentials=True can never be combined with an unrestricted CORS origin allowlist. The check compares the configured origin list to the wildcard using exact list equality (cors_origins == ["*"]) instead of a membership test. Any multi-entry origin configuration that merely includes "*" alongside other origins (e.g. cors_origins=*,https://trusted.example.com) bypasses the check entirely, while Starlette's underlying CORSMiddleware still treats the presence of "*" anywhere in the list as "allow all origins" and reflects the request's actual Origin header together with Access-Control-Allow-Credentials: true. This allows any website to read a victim's authenticated Glances monitoring data, including full process lists with command-line arguments, by exploiting the browser's automatic replay of cached HTTP Basic Auth credentials in a cross-origin request.
Details
glances/outputs/glances_restful_api.py:298:
if cors_origins == ["*"] and cors_credentials:
logger.warning(...)
cors_credentials = False
The intended guarantee is documented in glances/outputs/glances_stdout_api_restful_doc.py:247-260: "Setting cors_credentials=True with cors_origins= is not allowed. Glances will automatically disable credentials and log a warning if this combination is detected."* The exact-equality comparison only matches when cors_origins is precisely the single-element list ["*"]. Starlette's CORSMiddleware, by contrast, determines wildcard behavior via "*" in allow_origins, a membership test, so any multi-entry list containing "*" is still treated by Starlette as "allow all origins," while Glances's own guard silently fails to disable credentials for that case, breaking the documented guarantee with no warning logged.
This is the same exact-match-versus-membership-test bug shape that CVE-2026-46608 fixed in the sibling XML-RPC server (glances/server.py, which correctly performs if '*' in cors_origins:). The REST API's analogous check was never updated to the corrected pattern.
PoC
Configuration:
[outputs]
cors_origins=*,https://trusted.example.com
cors_credentials=true
# Confirm auth is required
curl -s -i http://127.0.0.1:36212/api/4/cpu
-> 401 Unauthorized, www-authenticate: Basic
# Authenticated request, Origin header set to an arbitrary domain never configured
curl -s -i -u glances:<password> -H "Origin: https://totally-evil-attacker.com" \
http://127.0.0.1:36212/api/4/cpu
-> 200 OK
access-control-allow-origin: https://totally-evil-attacker.com
access-control-allow-credentials: true
{"total": 0.0, "user": 0.0, ...}
# Same against the process list, exposing command lines/usernames/PIDs
curl -s -u glances:<password> -H "Origin: https://totally-evil-attacker.com" \
http://127.0.0.1:36212/api/4/processlist
-> [{"cmdline": [...], "username": "...", "pid": ..., ...}, ...]
(same access-control-allow-origin / access-control-allow-credentials headers)
Remediation suggestion
Change the check at glances_restful_api.py:298 from cors_origins == ["*"] to "*" in cors_origins, matching the corrected pattern already used in glances/server.py for the XML-RPC server.
Impact
Any operator who configures cors_origins as a multi-entry list that includes the wildcard alongside one or more specific trusted origins, a plausible configuration mistake given the documented default is the bare wildcard, and an operator attempting to additionally permit a second legitimate dashboard origin may not realize the wildcard must first be removed, silently loses the documented credentials-disable protection. Any third-party website can then read the full authenticated monitoring dataset of any visitor who has previously logged into that Glances instance via their browser, including process command-line arguments (which frequently contain secrets passed as CLI flags), usernames, and PIDs.
CVE-2026-68517 has a CVSS score of 6.5 (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.6); upgrading removes the vulnerable code path.
Affected versions
Security releases
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. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-68517? CVE-2026-68517 is a medium-severity security vulnerability in glances (pip), affecting versions < 4.5.6. It is fixed in 4.5.6.
- How severe is CVE-2026-68517? CVE-2026-68517 has a CVSS score of 6.5 (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-68517? glances (pip) versions < 4.5.6 is affected.
- Is there a fix for CVE-2026-68517? Yes. CVE-2026-68517 is fixed in 4.5.6. Upgrade to this version or later.
- Is CVE-2026-68517 exploitable, and should I be worried? Whether CVE-2026-68517 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-68517 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-68517? Upgrade
glancesto 4.5.6 or later.