GHSA-87qc-fj39-wccr

Summary

The Glances XML-RPC server (glances -s) introduced a configurable CORS origin list in version 4.5.3 as a mitigation for CVE 2026-33533. However, the implementation silently falls back to Access-Control-Allow-Origin: * whenever cors_origins contains more than one entry. An operator who configures an explicit two-entry allowlist (e.g. two internal dashboard origins) intending to restrict browser access instead receives the unrestricted wildcard — the same exposure that the original CVE described. A malicious web page served from any origin can issue a CORS simple request to /RPC2 and read the full system monitoring dataset without the victim's knowledge.

Details

Affected file: glances/server.py, class GlancesXMLRPCServer, line 113

Direct URL (commit 04579778e733d705898a169e049dc84772c852da):

• https://github.com/nicolargo/glances/blob/04579778e733d705898a169e049dc84772c852da/glances/server.py#L113

# server.py  (GlancesXMLRPCServer.__init__)
cors_origins = self.args.cors_origins   # list from config / CLI

# Line 113 — the incomplete fix:
self.cors_origin = cors_origins[0] if len(cors_origins) == 1 else '*'
#                                                                  ^^^
# Any allowlist with 2+ entries collapses to the wildcard

The cors_origin value is then echoed back as the Access-Control-Allow-Origin response header for every request (line ~147 in the same file):

self.send_header('Access-Control-Allow-Origin', self.cors_origin)

This means the CORS header is determined once at server startup and never compared against the actual Origin header sent by the browser. Even if an operator sets:

# glances.conf
[outputs]
cors_origins = https://dashboard.corp.example.com,https://grafana.corp.example.com

the server responds with Access-Control-Allow-Origin: * to every request, including those from https://attacker.example.com.

Single-origin wildcard (the default,...