GHSA-4h34-v6r8-mmjc: Infoleak

Summary

Glances provides asdictsecure() explicitly designed for unauthenticated API access, with a docstring stating it returns "a sanitised copy of the configuration dict" where "Sensitive keys in remaining sections are replaced by ''". However, the implementation only checks KEY names against a regex pattern and never inspects VALUE content. The documented [ip] config section supports publicapi (URL), publicusername (login), and publicpassword (password). While publicpassword is correctly masked, both publicapi (when containing embedded credentials like https://user:pass@host/) and publicusername are returned in full to unauthenticated users via GET /api/4/config.

Affected Versions

Glances latest (Docker: nicolargo/glances:latest)

Root Cause

In glances/config.py, asdictsecure(): python SECURESENSITIVEKEYRE = re.compile(r"password|token|secret|apikey|apikey|sslkeyfile", re.IGNORECASE)

def asdictsecure(self): """Return a sanitised copy of the configuration dict. Intended for unauthenticated API access. - Sensitive keys in remaining sections are replaced by ''. """ sanitized = {} for section, options in self.asdict().items(): if section in SECUREBLOCKEDSECTIONS: continue sanitized[section] = { key: "" if SECURESENSITIVEKEYRE.search(key) else value for key, value in options.items() } return sanitized

In glances/outputs/glancesrestfulapi.py: python Line 1294 argsjson = self.config.asdict() if self.args.password else self.config.asdictsecure()

The [ip] config section documents: publicapi (URL), publicusername (login), publicpassword (password). - publicpassword → matches "password" → masked ✓ - publicapi → no match → returned in full (contains user:pass@ in URL) ✗ - publicusername → no match → returned in full ✗

Impact

- Unauthenticated credential disclosure via GET /api/4/config or GET /api/4/config/ip - asdictsecure() exists specifically to protect credentials in no-auth mode but fails to mask publicusername and credential-bearing URLs in publicapi

Prerequisites

- Glances in web server mode without --password (default, no auth) - glances.conf [ip] section with publicapi containing embedded credentials and/or publicusername set

Environment

- Glances latest (Docker: nicolargo/glances:latest) - Remote Docker lab at http://10.140.200.102:8080

Reproduction Steps

bash docker run -d --name glances-test -p 8080:61208 -e GLANCESOPT='-w' nicolargo/glances:latest sleep 20 docker exec glances-test sed -i 's|publicapi=https://ipv4.ipleak.net/json/|publicapi=https://admin:secret123@ipv4.ipleak.net/json/|' /etc/glances/glances.conf docker exec glances-test sed -i 's|#publicusername=<myname>|publicusername=myname|' /etc/glances/glances.conf docker exec glances-test sed -i 's|#publicpassword=<mysecret>|publicpassword=mysecret|' /etc/glances/glances.conf docker restart glances-test sleep 15 curl -s "$TARGET/api/4/config/ip" Returns: {"publicapi": "https://admin:secret123@...", "publicusername": "myname", "publicpassword": ""}

Evidence

See C:/Tools/glances-config-leak-evidence.txt.

Dedup Check

- GHSA-gfc2-9qmw-w7vh covers CORS but NOT value-level credential leak - No existing GHSA covers asdictsecure() value-level filtering gap - 13 published GHSA, none covering this issue

Suggested Remediation

Add "username" and "login" to sensitive key pattern, and check values for embedded credentials in URLs.

Disclosure Timeline

- 2026-07-28: Vulnerability discovered and verified via Docker deployment

Reporter

GitHub username: Todor