CVE-2026-68520 is a medium-severity (CVSS 5.3) Information Exposure vulnerability in glances. O3 Security confirms whether CVE-2026-68520 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Glances: as_dict_secure() Value-Level Bypass Leaks Credentials in URL Values via /api/4/config
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-68520.
Real-World Exposure
glancesReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
Summary
Glances provides as_dict_secure() 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 public_api (URL), public_username (login), and public_password (password). While public_password is correctly masked, both public_api (when containing embedded credentials like https://user:pass@host/) and public_username 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, as_dict_secure():
_SECURE_SENSITIVE_KEY_RE = re.compile(r"password|token|secret|api_key|apikey|ssl_keyfile", re.IGNORECASE)
def as_dict_secure(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.as_dict().items():
if section in _SECURE_BLOCKED_SECTIONS: continue
sanitized[section] = {
key: "********" if _SECURE_SENSITIVE_KEY_RE.search(key) else value
for key, value in options.items()
}
return sanitized
In glances/outputs/glances_restful_api.py:
# Line 1294
args_json = self.config.as_dict() if self.args.password else self.config.as_dict_secure()
The [ip] config section documents: public_api (URL), public_username (login), public_password (password).
public_password→ matches "password" → masked ✓public_api→ no match → returned in full (containsuser:pass@in URL) ✗public_username→ no match → returned in full ✗
Impact
- Unauthenticated credential disclosure via
GET /api/4/configorGET /api/4/config/ip as_dict_secure()exists specifically to protect credentials in no-auth mode but fails to maskpublic_usernameand credential-bearing URLs inpublic_api
Prerequisites
- Glances in web server mode without
--password(default, no auth) glances.conf[ip]section withpublic_apicontaining embedded credentials and/orpublic_usernameset
Environment
- Glances latest (Docker:
nicolargo/glances:latest) - Remote Docker lab at
http://10.140.200.102:8080
Reproduction Steps
docker run -d --name glances-test -p 8080:61208 -e GLANCES_OPT='-w' nicolargo/glances:latest
sleep 20
docker exec glances-test sed -i 's|public_api=https://ipv4.ipleak.net/json/|public_api=https://admin:[email protected]/json/|' /etc/glances/glances.conf
docker exec glances-test sed -i 's|#public_username=<myname>|public_username=myname|' /etc/glances/glances.conf
docker exec glances-test sed -i 's|#public_password=<mysecret>|public_password=mysecret|' /etc/glances/glances.conf
docker restart glances-test
sleep 15
curl -s "$TARGET/api/4/config/ip"
# Returns: {"public_api": "https://admin:secret123@...", "public_username": "myname", "public_password": "********"}
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
as_dict_secure()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
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | glances | all versions | 4.5.6 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for glances. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update glances to 4.5.6 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-68520 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether CVE-2026-68520 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to CVE-2026-68520. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2026-68520 in your dependencies?
O3 detects CVE-2026-68520 across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.