CVE-2026-68517: Glances: REST API CORS Credentials Guard Uses Exact-Match Instead of Membership Test — Bypassed by Any Multi-Origin Allowlist Containing the Wildcard

Summary Glances's REST API server includes a documented safety check intended to guarantee that corscredentials=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 (corsorigins == [""]) instead of a membership test. Any multi-entry origin configuration that merely includes "" alongside other origins (e.g. corsorigins=,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/glancesrestfulapi.py:298: python if corsorigins == [""] and corscredentials: logger.warning(...) corscredentials = False The intended guarantee is documented in glances/outputs/glancesstdoutapirestfuldoc.py:247-260: "Setting corscredentials=True with corsorigins= is not allowed. Glances will automatically disable credentials and log a warning if this combination is detected." The exact-equality comparison only matches when corsorigins is precisely the single-element list [""]. Starlette's CORSMiddleware, by contrast, determines wildcard behavior via "" in alloworigins — 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 corsorigins:). The REST API's analogous check was never updated to the corrected pattern.

PoC Configuration: ini [outputs] corsorigins=,https://trusted.example.com corscredentials=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)

Impact Any operator who configures corsorigins 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.

Remediation suggestion Change the check at glancesrestfulapi.py:298 from corsorigins == [""] to "" in corsorigins, matching the corrected pattern already used in glances/server.py for the XML-RPC server.