☠️
EXFILTRATING
DATA...
01010111 10110010 00101001 11000110 01101100 10011011 00010001 11100101 01000010 10101111
[ <-- BACK_TO_SEARCH ]
[ VENDOR STATS ]
CVSS: 5.3 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N 🐛 CWE-200
👁️
Common Weakness Enumeration - Identifies the specific category of software weakness or flaw.

CVE-2026-68520

CVE-2026-68520 Vulnerability in Glances
📅 PUBLISHED: 2026-08-17 00:00 UTC 🔄 UPDATED: 2026-09-23 20:33 UTC
[ PATCH UNDER REVIEW ↓ ] Remains UNDER REVIEW until an independent source confirms the fix
[ DEFENSE PATCH ↓ ]
💣 PoC: None
👁️
Proof of Concept - Indicates if functional exploit code is publicly available, drastically increasing the risk of immediate attacks.
🎯 EPSS: 0.30%
👁️
0.30% probability
7.4× above the median CVE
Tier: ELEVATED
30-day exploitation window · FIRST.org · updated daily
🥷 MITRE: T1190
👁️
MITRE ATT&CK Tactic - Describes the strategy hackers use to execute this attack.
VULNERABLE: version not auto-detected — verify your deployed version locally
CVSS VECTOR BREAKDOWN 5.3
AV: N Attack Vector Network
AC: L Attack Complexity Low
PR: N Privileges Required None
UI: N User Interaction None
S: U Scope Unchanged
C: L Confidentiality Low
I: N Integrity None
A: N Availability None
5.3
THREAT LEVEL
■ tracking this CVE ✓ independent patch confirmation ⧗ same-origin mirror (GHSA) ⚠ active exploitation verification policy →

Executive Summary

CVE-2026-68520 is an unauthenticated information-disclosure vulnerability in Glances, an open-source cross-platform system monitoring tool, affecting versions prior to 4.5.6. The as_dict_secure() function in glances/config.py filters sensitive configuration by option name only and fails to redact public_username and credentials embedded in public_api values, which are then returned by the unauthenticated GET /api/4/config and GET /api/4/config/ip endpoints. An unauthenticated remote attacker can harvest credential material from any network-exposed Glances instance, with a CVSS base score of 5.3 (Medium) reflecting low confidentiality impact but trivial remote exploitation.

⚡ AUTOMATE YOUR CVE INTELLIGENCE

This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.

›Patch confidence — UNVERIFIED to CONFIRMED, cross-referenced NVD + RHSA + Debian
›Exploit & PoC — poc_status, poc_url, has_exploit. Not in NVD.
›Shodan dorks — ready-made queries to find exposed vulnerable systems
›Detection rules — YARA · Wazuh · Elastic (all plans) · Sigma (Pro)
›pending_fields — know exactly which of 7 fields NVD hasn't processed yet
›Free backfill — data incomplete when you paid? Re-check within 30 days = 0 credits
PAYG €0.08/lookup Standard €19/mo (was €29) · 5k credits Pro €65/mo (was €99) · 20k credits FOUNDING PRICE · LOCKED FOR LIFE · ENDS 31 DEC 2026
[ FROM €19/MO ]
Free sandbox key available
No signup required

Technical Analysis

The vulnerability is a sanitization/redaction bypass in the Glances configuration serialization path. Glances exposes a REST API that returns configuration data, and the as_dict_secure() routine in glances/config.py is responsible for removing or masking sensitive entries before the data is serialized and served to clients. According to the NVD description, the routine evaluates only the names of configuration options when deciding what to strip. It does not recursively inspect the values of permitted options for embedded secret material.

Two consequences follow directly from this incomplete filtering design:

  1. The public_username option itself is exposed verbatim in API responses. Because its name does not match the filter's criteria for sensitive keys, the value is included unchanged in the returned configuration document.
  2. Credentials embedded inside public_api values are likewise returned unredacted. The public_api option is an allowed configuration key, and the sanitizer never scans its content for credential-like patterns (e.g., username/password material embedded in URI or connection strings). Any secret placed inside that value survives serialization and is served to the caller.

The exposure surface is the unauthenticated REST API. Both GET /api/4/config and GET /api/4/config/ip serve configuration data to any client that can reach the Glances HTTP listener; the CVSS vector confirms the attack requires no privileges (PR:N) and no user interaction (UI:N), and has low attack complexity (AC:L), meaning a single well-formed HTTP GET request is sufficient to trigger disclosure. The attack vector is network (AV:N), so any Glances deployment whose API is reachable — including instances exposed to the internet, placed on flat internal networks, or published via container port mappings — is potentially affected.

From a vulnerability-class perspective, this is a CWE-200 (Exposure of Sensitive Information) defect caused by an incomplete denylist-based sanitization routine: the function's security decision is made solely on the attribute name rather than on the content of the attribute's value. Function names, file path, and endpoints referenced above (as_dict_secure(), glances/config.py, GET /api/4/config, GET /api/4/config/ip, public_username, public_api, version 4.5.6) are taken verbatim from the NVD description; no additional implementation details are available in the supplied intelligence data.

The CVSS vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N yields the base score 5.3 and confirms the scope is unchanged, confidentiality impact is Low, and there is no direct integrity or availability impact. EPSS has not yet scored this CVE by FIRST.org, and CISA KEV does not currently list CVE-2026-68520. No public PoC or exploit code was identified in the provided data.

Exploitation Scenarios

No public exploit code or PoC is available in the intelligence data provided; the attack chain below is inferred strictly from the NVD description and the vulnerability class.

Step 1 — Reconnaissance / target identification. The attacker identifies Glances instances exposed on the network. Typical discovery methods include Shodan queries for Glances web UI banners/titles, service fingerprinting, port scanning of hosts running monitoring agents, or direct probing for known REST API path patterns. Because the API requires no authentication, simply confirming that a host responds on the Glances HTTP listener is sufficient to qualify it as a target.

Step 2 — Triggering the flaw. The attacker sends unauthenticated HTTP GET requests to the configuration endpoints, specifically GET /api/4/config and GET /api/4/config/ip. No session, token, or privileged account is required — the CVSS vector (PR:N, UI:N) confirms that the vulnerability is reachable without prior access.

Step 3 — Execution / data return. There is no injection payload or code execution involved. The server-side serialization path calls as_dict_secure(), which strips only those options it recognizes by name as sensitive. Since the routine does not inspect option values, the resulting JSON response contains the public_username value verbatim and any credentials embedded within public_api values. The attacker simply reads the returned configuration document — the disclosure occurs automatically as a side effect of the normal API response.

Step 4 — Post-exploitation impact. The attacker harvests usernames and embedded credentials from the response. These credentials may relate to remote endpoints or services that the monitored host connects to, and can be leveraged for credential stuffing, direct authentication to those services, or as a foothold for lateral movement. Because Glances is a system monitoring tool, the compromised configuration may also reveal network topology, host attributes, and integration points that support further reconnaissance. The CVSS model rates the confidentiality impact as Low (C:L), but leakage of reusable credentials typically warrants elevated practical risk assessment by defenders.

Impact Assessment

Affected systems. Self-hosted Glances installations running versions prior to 4.5.6 that expose the REST API to any network segment reachable by untrusted parties — including internet-facing deployments, container images with published ports, and monitoring jump hosts on internal networks. Assets whose public_api configuration contains embedded credentials, or which define a non-empty public_username, are the most directly impacted.

Business impact. Monitoring infrastructure occupies a privileged position in most environments: it typically holds credentials or network access to many other systems so that it can poll their status. A configuration disclosure on such a host therefore carries outsized risk. The credentials exposed by this CVE may grant access to third-party services, remote API endpoints, or other monitored assets, enabling account takeover, credential stuffing campaigns, and lateral movement. Even if the leaked credentials are low-privileged, their presence in unauthenticated API responses violates the principle of least privilege and may trigger compliance obligations for credential/secret handling.

Blast radius. The CVSS base score is 5.3 (Medium) with an exploitability side of the vector that is highly favorable to attackers: network attack vector, low complexity, no privileges required, and no user interaction. The impact subscores are limited to Low confidentiality, with no integrity or availability impact, so the direct footprint of a single request is narrow. However, the practical blast radius expands if the leaked credentials are reused elsewhere, propagate across integrations, or are combined with other findings during an attack campaign. No exploit-in-the-wild evidence or threat actor campaigns were reported in the provided data, but this should not be treated as assurance of safety — information-disclosure flaws in exposed monitoring tools are routinely targeted once identified.

Detection Guidance

Detection strategies should focus on (a) unauthenticated access to the Glances configuration API endpoints, and (b) response bodies containing the exposed public_username / public_api fields. The rules below assume HTTP access logs, network traffic capture, or endpoint log ingestion. Fine-tune thresholds to your environment to reduce noise from legitimate monitoring automation.

Sigma Rule

title: CVE-2026-68520 Glances Config API Unauthenticated Access
id: 8a4f2c91-7b5e-4d2a-9c3f-1d6e0a5b7c42
status: experimental
description: Detects unauthenticated HTTP GET requests to the Glances REST API configuration endpoints /api/4/config and /api/4/config/ip, associated with CVE-2026-68520 credential disclosure.
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2026-68520
author: Valters IT Threat Intelligence
date: 2026
logsource:
    category: webserver
    product: generic
detection:
    selection:
        cs-method: GET
        cs-uri-stem|startswith:
            - /api/4/config
    condition: selection
fields:
    - c-ip
    - cs-uri-stem
    - sc-status
    - cs(user-agent)
falsepositives:
    - Legitimate administrators or monitoring automation querying Glances configuration
    - Health-check scripts that periodically retrieve configuration
level: medium

YARA Rule

rule Glances_CVE_2026_68520_Config_Exposure_Indicators
{
    meta:
        author = "Valters IT Threat Intelligence"
        description = "Detects HTTP artifacts, logs, and source references associated with CVE-2026-68520 exposure of the Glances /api/4/config endpoints"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-68520"
        cve = "CVE-2026-68520"
        date = "2026"
    strings:
        $endpoint_ip = "/api/4/config/ip" ascii wide
        $endpoint = "/api/4/config" ascii wide
        $leak_username = "public_username" ascii wide
        $vuln_func = "as_dict_secure" ascii wide
        $leak_api = "public_api" ascii wide
    condition:
        any of ($endpoint_ip, $endpoint, $leak_username, $vuln_func, $leak_api)
}

Suricata IDS Rule

# Request-side detection: unauthenticated access to Glances config API
alert http any any -> any any (msg:"CVE-2026-68520 Glances /api/4/config unauthenticated access attempt"; flow:established,to_server; content:"GET"; http.method; content:"/api/4/config"; http.uri; startswith; classtype:attempted-recon; reference:cve,2026-68520; sid:202668520; rev:1;)

# Response-side detection: server response exposing sensitive config fields
alert http any any -> any any (msg:"CVE-2026-68520 Glances config API response exposing credentials"; flow:established,to_client; content:"public_username"; http.response_body; content:"public_api"; http.response_body; distance:0; within:8192; classtype:successful-recon; reference:cve,2026-68520; sid:202668521; rev:1;)

Elastic Detection

// Single-event detection on network/HTTP events
network where network.protocol == "http"
    and http.request.method == "GET"
    and url.path in ("/api/4/config", "/api/4/config/ip")
// Sequence variant: request followed by a 200 response, indicating likely successful retrieval
sequence by source.ip
  [ network where network.protocol == "http"
        and http.request.method == "GET"
        and url.path in ("/api/4/config", "/api/4/config/ip") ]
  [ network where network.protocol == "http"
        and http.response.status_code == 200 ]

Splunk SPL Query

index=web sourcetype=access_combined*
  | where like(uri_path, "/api/4/config%") AND like(method, "GET")
  | stats count AS request_count,
         earliest(_time) AS first_seen,
         latest(_time) AS last_seen
    BY src_ip, dest_ip, uri, status, useragent
  | sort 100 - request_count

Wazuh OSSEC Rule

<group name="web,glances,">
  <rule id="100685" level="10" frequency="5" timeframe="120">
    <if_matched_sid>31100</if_matched_sid>
    <match>GET /api/4/config</match>
    <description>CVE-2026-68520: Repeated unauthenticated access to Glances config API (/api/4/config or /api/4/config/ip) detected.</description>
    <group>web_application_attack,</group>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 — no patch evidence from any tracked source. Note that the NVD description states the issue is fixed in Glances 4.5.6, but no vendor advisory, changelog excerpt, or patch diff has been verified by the tracked patch sources. Treat all deployments below 4.5.6 as vulnerable until you independently confirm the upstream fix.

  1. Immediate mitigations. Restrict network access to the Glances REST API using host firewalls, security groups, or network segmentation so that only trusted administrative hosts can reach it. Place a reverse proxy with mandatory authentication in front of the Glances web UI/API if remote access is required. If the REST API is not needed for your use case, disable it entirely. Rotate any credentials that are embedded in public_api values or associated with public_username, since they may already have been exfiltrated if the instance was exposed. Remove credential material from configuration values; prefer revocable tokens, API keys, or alternative authentication mechanisms that do not require embedding secrets in plaintext configuration.

  2. Patch / upgrade steps. Upgrade Glances to version 4.5.6 or later once you have verified the release and its change log through official project channels. After upgrading, confirm that as_dict_secure() no longer returns public_username or credentials embedded in public_api values by querying the configuration endpoints and inspecting the response. Roll out the update to all affected hosts, including containerized Glances deployments, and validate monitoring functionality after the change.

  3. Long-term hardening. Treat the monitoring host as a high-value asset: it has privileged visibility into the environment and should never be directly exposed to the internet. Enforce authentication for the web UI/API in all deployments. Implement secret scanning for configuration files to prevent credentials from being committed or embedded in public_api values. Monitor access logs for /api/4/config and /api/4/config/ip requests and alert on unauthenticated access from unfamiliar sources. Revisit network segmentation so that monitoring tools can only reach their intended targets, limiting the blast radius if credentials leak. Since EPSS has not yet scored this CVE and no in-the-wild exploitation is recorded, there is a narrow window to remediate proactively before weaponized tooling becomes common.

References

👁️ SHODAN DORKS (THREAT HUNTING)

What is this? Security researchers use these exact search queries on Shodan.io (a search engine for internet-connected devices) to find vulnerable systems globally. You can copy these dorks to see if your organization's IP space is exposed.

title:"Glances"
http.html:"Glances Web UI"
"/api/4/config"
product:"Glances"
◈ SOURCE Analysis & enrichment: valtersit.com/cve/CVE-2026-68520/ · CVE data: NVD/MITRE (public domain) · © 2026 ValtersIT Hub
>_ SYSTEM_CORE: INTEL_ACTIVE
90% TEAM-CURATED // 10% AUTOMATED INGESTION.
ALL PATCH REFERENCES AND VERSION DATA SOURCED FROM NVD + OSV OFFICIAL REGISTRIES.