Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
26 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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(): In glances/outputs/glancesrestfulapi.py: The [ip] config section documents: publicapi (URL), publicusername (login), publicpassword (password). - publicpassword → matches "password" → masked ✓ - publicapi →…
Recommended action: Upgrade to 4.5.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Glances 4.5.5 the --disable-config-exec flag was extended (GHSA-3vwc-qwhc-3mj7) to stop securepopen() from interpreting the shell operators &&, | and in AMP command values taken from the configuration file. The hardening was not applied to the on-alert action command path, which reads its command lines from the same configuration file. As a result, with --disable-config-exec enabled, a configured alert action that contains (file redirection), && (chaining) or | (pipe) still has those operators interpreted, allowing arbitrary file write / command chaining at the privilege of the glances process when the alert triggers. Affected code glances/actions.py (Glances 4.5.5, latest): By contrast the AMP modules were fixed: PoC (benign) glances.conf: Run glances --disable-config-exec and generate CPU load. When the cpu user alert reaches CRITICAL, /tmp/pocmarker is created — i.e. the operator was interpreted despite --disable-config-exec. The same in an [amp] command value is…
Recommended action: Upgrade to 4.5.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
CVE-2026-32608 ("Command Injection via Process Names in Action Command Templates") was fixed (commit 5680a5d) by adding sanitizemustachedict, which replaces the shell operators &&, |, , with spaces in the values rendered into action command templates. The sanitizer only processes top-level string values (if isinstance(v, str)). Attacker-controlled nested values — most notably a process's cmdline, which Glances exposes as a list and which is fully attacker-controlled via argv — are passed through unsanitized. Because the Mustache renderer (chevron) does not HTML-escape the pipe character |, a | embedded in such a nested value survives into the rendered command and is then interpreted by securepopen (which still interprets &&/|/ by default, allowoperators=True), re-introducing the exact command injection the CVE was meant to close. Details The fix (glances/actions.py): Render + sink (glances/actions.py:104-111): securepopen (glances/secure.py:17, default allowoperators=True)…
Recommended action: Upgrade to 4.5.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 4.5.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Glances action system lets an administrator configure shell commands that run when a monitoring threshold is crossed. The command is a Mustache template whose variables are filled with runtime stat fields such as a process name, a container name or a filesystem mount point. Those fields are attacker-influenceable: a local, unprivileged user who starts a process (or a container) controls its name and command line. The rendered command is executed by securepopen(), which interprets &&, | and as chaining / pipe / redirection operators. glances/actions.py defends against this with sanitizemustachedict(), which strips those operators from each individual template value before rendering. The sanitization is applied per field, but the operators are reconstructed across the boundary of two adjacent template variables after Mustache rendering. When an action template concatenates two unescaped variables ({{{a}}}{{{b}}} or {{&a}}{{&b}}) and the attacker makes the first value end…
Recommended action: Upgrade to 4.5.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The securepopen() function in glances/secure.py interprets (file redirection), | (pipe), and && (command chaining) operators in command strings. These operators are applied without any validation on the target file path, piped command, or chained command. When Application Monitoring Process (AMP) modules load their command or servicecmd configuration values from glances.conf, those values are passed directly to securepopen() with no sanitization. This allows an attacker who can modify the Glances configuration file to write arbitrary content to arbitrary filesystem paths (via ), chain arbitrary commands (via &&), or pipe command output to arbitrary programs (via |). Crucially, this vulnerability is not mitigated by the --disable-config-exec flag that was introduced to address CVE-2026-33641. That flag only disables backtick command execution in config.getvalue(); it does not affect the securepopen() function's interpretation of shell-like operators. Details Affected code path…
Recommended action: Upgrade to 4.5.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Glances XML-RPC server (glances -s, implemented in glances/server.py) does not validate the HTTP Host header, leaving it vulnerable to DNS rebinding attacks. CVE-2026-32632 (patched in 4.5.2) added TrustedHostMiddleware to the REST/WebUI server; the MCP server has had equivalent protection since 4.5.1. The XML-RPC server received neither fix and has no allowed-hosts configuration key. Combined with the unrestricted Access-Control-Allow-Origin: header (see companion advisory for CVE-2026-33533 and its incomplete fix), an attacker can exploit DNS rebinding to exfiltrate the full system monitoring dataset from a victim's browser. --- Details Affected component: glances/server.py — GlancesXMLRPCHandler / GlancesXMLRPCServer Direct URL (commit 04579778e733d705898a169e049dc84772c852da): - https://github.com/nicolargo/glances/blob/04579778e733d705898a169e049dc84772c852da/glances/server.py Contrast — patched backends: -…
Recommended action: Upgrade to 4.5.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 corsorigins 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 The corsorigin value is then echoed back as the Access-Control-Allow-Origin…
Recommended action: Upgrade to 4.5.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
glances/outdated.py uses pickle.load() to read a version-check cache file stored at a predictable, world-accessible path (~/.cache/glances/glances-version.db or $XDGCACHEHOME/glances/glances-version.db). No integrity check, signature verification, or format validation is performed before deserialization. An attacker with write access to that path — through any of several realistic local or container-level scenarios — can plant a malicious pickle file and achieve arbitrary code execution as the OS user running Glances the next time it starts with version checking enabled (the default). --- Details Affected file: glances/outdated.py, method Outdated.loadcache(), line 121 Direct URL (commit 04579778e733d705898a169e049dc84772c852da): - https://github.com/nicolargo/glances/blob/04579778e733d705898a169e049dc84772c852da/glances/outdated.py#L121 self.cachefile is constructed from the XDG cache directory path at Outdated.init(): On a default Linux installation this resolves to…
Recommended action: Upgrade to 4.5.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Glances KVM/QEMU monitoring engine (glances/plugins/vms/engines/virsh.py) passes VM domain names, read directly from virsh list --all output, into f-string command templates that are processed by securepopen(). securepopen() is explicitly designed to interpret &&, |, and as shell operators. Because domain names are never sanitised before interpolation, any user with the ability to create or rename a KVM/QEMU virtual machine can execute arbitrary commands as the OS user running Glances — commonly root on hypervisor hosts. --- Details Affected file: glances/plugins/vms/engines/virsh.py Direct URLs (commit 04579778e733d705898a169e049dc84772c852da): - https://github.com/nicolargo/glances/blob/04579778e733d705898a169e049dc84772c852da/glances/plugins/vms/engines/virsh.py#L185 - https://github.com/nicolargo/glances/blob/04579778e733d705898a169e049dc84772c852da/glances/plugins/vms/engines/virsh.py#L204 The vulnerable calls are on lines 185 and 204: domain is the name string…
Recommended action: Upgrade to 4.5.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Cassandra export module (glances/exports/glancescassandra/init.py) interpolates keyspace, table, and replicationfactor configuration values directly into CQL statements without validation. A user with write access to glances.conf can redirect all monitoring data to an attacker-controlled Cassandra keyspace. Vulnerable Code Steps to Reproduce 1. Configure glances.conf with malicious table value: 2. Create attacker keyspace in Cassandra 3. Run glances --export cassandra 4. All monitoring data is written to attackerks.capturedstats instead of the legitimate table Confirmed output: Impact All exported monitoring data (CPU, memory, network, disk I/O) is silently redirected to an attacker-controlled Cassandra keyspace — both data exfiltration and data loss. Proposed Fix
Recommended action: Upgrade to 4.5.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Server-Side Request Forgery (SSRF) vulnerability exists in the Glances IP plugin due to improper validation of the publicapi configuration parameter. The value of publicapi is used directly in outbound HTTP requests without any scheme restriction or hostname/IP validation. An attacker who can modify the Glances configuration can force the application to send requests to arbitrary internal or external endpoints. Additionally, when publicusername and publicpassword are set, Glances automatically includes these credentials in the Authorization: Basic header, resulting in credential leakage to attacker-controlled servers. This vulnerability can be exploited to: Access internal network services (e.g., 127.0.0.1, 192.168.x.x) Retrieve sensitive data from cloud metadata endpoints (e.g., 169.254.169.254) Exfiltrate credentials via outbound HTTP requests The issue arises because publicapi is passed directly to the HTTP client (urlopenauth) without validation, allowing unrestricted…
Recommended action: Upgrade to 4.5.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Glances web server exposes a REST API (/api/4/) that is accessible without authentication and allows cross-origin requests from any origin due to a permissive CORS policy (Access-Control-Allow-Origin: ). This allows a malicious website to read sensitive system information from a running Glances instance in the victim’s browser, leading to cross-origin data exfiltration. While a previous advisory exists for XML-RPC CORS issues, this report demonstrates that the REST API (/api/4/) is also affected and exposes significantly more sensitive data. Details When Glances is started in web mode (e.g., glances -w -B 0.0.0.0), it exposes a REST API endpoint at: http://<host:61208/api/4/all The server responds with: Access-Control-Allow-Origin: This allows any origin to perform cross-origin requests and read responses. The /api/4/all endpoint returns extensive system information, including: - Process list (processlist) - System details (hostname, OS, CPU info) - Memory and disk usage…
Recommended action: Upgrade to 4.5.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Glances supports dynamic configuration values in which substrings enclosed in backticks are executed as system commands during configuration parsing. This behavior occurs in Config.getvalue() and is implemented without validation or restriction of the executed commands. If an attacker can modify or influence configuration files, arbitrary commands will execute automatically with the privileges of the Glances process during startup or configuration reload. In deployments where Glances runs with elevated privileges (e.g., as a system service), this may lead to privilege escalation. Details 1. Glances loads configuration files from user, system, or custom paths during initialization. 2. When retrieving a configuration value, Config.getvalue() scans for substrings enclosed in backticks. File: glances/config.py 3. The extracted string is passed directly to systemexec(). File: glances/globals.py 4. The command is executed and its output replaces the original configuration value.…
Recommended action: Upgrade to 4.5.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Glances XML-RPC server (activated with glances -s or glances --server) sends Access-Control-Allow-Origin: on every HTTP response. Because the XML-RPC handler does not validate the Content-Type header, an attacker-controlled webpage can issue a CORS "simple request" (POST with Content-Type: text/plain) containing a valid XML-RPC payload. The browser sends the request without a preflight check, the server processes the XML body and returns the full system monitoring dataset, and the wildcard CORS header lets the attacker's JavaScript read the response. The result is complete exfiltration of hostname, OS version, IP addresses, CPU/memory/disk/network stats, and the full process list including command lines (which often contain tokens, passwords, or internal paths). Details File: glances/server.py, class GlancesXMLRPCHandler, line 41 This header is attached to every response from the XML-RPC server. The server inherits from SimpleXMLRPCRequestHandler which parses the POST…
Recommended action: Upgrade to 4.5.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Central Browser mode, Glances stores both the Zeroconf-advertised server name and the discovered IP address for dynamic servers, but later builds connection URIs from the untrusted advertised name instead of the discovered IP. When a dynamic server reports itself as protected, Glances also uses that same untrusted name as the lookup key for saved passwords and the global [passwords] default credential. An attacker on the same local network can advertise a fake Glances service over Zeroconf and cause the browser to automatically send a reusable Glances authentication secret to an attacker-controlled host. This affects the background polling path and the REST/WebUI click-through path in Central Browser mode. Details Dynamic server discovery keeps both a short name and a separate ip: The Zeroconf listener populates those fields directly from the service advertisement: However, the Central Browser connection logic ignores server['ip'] and instead uses the untrusted advertised…
Recommended action: Upgrade to 4.5.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Central Browser mode, the `/api/4/serverslist` endpoint returns raw server objects from `GlancesServersList.get_servers_list()`. Those objects are mutated in-place during background polling and can contain a `uri` field with embedded HTTP Basic credentials for downstream Glances servers, using the reusable pbkdf2-derived Glances authentication secret. If the front Glances Browser/API instance is started without `--password`, which is supported and common for internal network deployments, `/api/4/serverslist` is completely unauthenticated. Any network user who can reach the Browser API can retrieve reusable credentials for protected downstream Glances servers once they have been polled by the browser instance. Details The Browser API route simply returns the raw servers list: ```python glances/outputs/glances_restful_api.py:799-805 def _api_servers_list(self): self.__update_servers_list() return GlancesJSONResponse(self.servers_list.get_servers_list() if…
Recommended action: Upgrade to 4.5.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Glances recently added DNS rebinding protection for the MCP endpoint, but the main REST/WebUI FastAPI application still accepts arbitrary Host headers and does not apply TrustedHostMiddleware or an equivalent host allowlist. As a result, the REST API, WebUI, and token endpoint remain reachable through attacker-controlled domains in classic DNS rebinding scenarios. Once the victim browser has rebound the attacker domain to the Glances service, same-origin policy no longer protects the API because the browser considers the rebinding domain to be the origin. This is a distinct issue from the previously reported default CORS weakness. CORS is not required for exploitation here because DNS rebinding causes the victim browser to treat the malicious domain as same-origin with the rebinding target. Details The MCP endpoint now has explicit host-based transport security: However, the main FastAPI application for REST/WebUI/token routes is initialized without any host validation…
Recommended action: Upgrade to 4.5.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The GHSA-x46r fix (commit 39161f0) addressed SQL injection in the TimescaleDB export module by converting all SQL operations to use parameterized queries and psycopg.sql composable objects. However, the DuckDB export module (glances/exports/glancesduckdb/init.py) was not included in this fix and contains the same class of vulnerability: table names and column names derived from monitoring statistics are directly interpolated into SQL statements via f-strings. While DuckDB INSERT values already use parameterized queries (? placeholders), the DDL construction and table name references do not escape or parameterize identifier names. Details The DuckDB export module constructs SQL DDL statements by directly interpolating stat field names and plugin names into f-strings. Vulnerable CREATE TABLE construction (glances/exports/glancesduckdb/init.py:156-162): The creationlist is built from stat dictionary keys in the update() method (glances/exports/glancesduckdb/init.py:117-118): The…
Recommended action: Upgrade to 4.5.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Glances REST API web server ships with a default CORS configuration that sets alloworigins=[""] combined with allowcredentials=True. When both of these options are enabled together, Starlette's CORSMiddleware reflects the requesting Origin header value in the Access-Control-Allow-Origin response header instead of returning the literal wildcard. This effectively grants any website the ability to make credentialed cross-origin API requests to the Glances server, enabling cross-site data theft of system monitoring information, configuration secrets, and command line arguments from any user who has an active browser session with a Glances instance. Details The CORS configuration is set up in glances/outputs/glancesrestfulapi.py lines 290-299: The defaults are loaded from the config file, but when no config is provided (which is the common case for most deployments), the defaults are: - corsorigins = [""] (all origins) - corscredentials = True (allow credentials) Per the CORS…
Recommended action: Upgrade to 4.5.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The GHSA-gh4x fix (commit 5d3de60) addressed unauthenticated configuration secrets exposure on the /api/v4/config endpoints by introducing asdictsecure() redaction. However, the /api/v4/args and /api/v4/args/{item} endpoints were not addressed by this fix. These endpoints return the complete command-line arguments namespace via vars(self.args), which includes the password hash (salt + pbkdf2hmac), SNMP community strings, SNMP authentication keys, and the configuration file path. When Glances runs without --password (the default), these endpoints are accessible without any authentication. Details The secrets exposure fix (GHSA-gh4x, commit 5d3de60) modified three config-related endpoints to use asdictsecure() when no password is configured: However, the apiargs and apiargsitem endpoints were not part of this fix and still return all arguments without any sanitization: And the item-specific endpoint: The self.args namespace contains sensitive fields set during initialization in…
Recommended action: Upgrade to 4.5.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Glances action system allows administrators to configure shell commands that execute when monitoring thresholds are exceeded. These commands support Mustache template variables (e.g., {{name}}, {{key}}) that are populated with runtime monitoring data. The securepopen() function, which executes these commands, implements its own pipe, redirect, and chain operator handling by splitting the command string before passing each segment to subprocess.Popen(shell=False). When a Mustache-rendered value (such as a process name, filesystem mount point, or container name) contains pipe, redirect, or chain metacharacters, the rendered command is split in unintended ways, allowing an attacker who controls a process name or container name to inject arbitrary commands. Details The action execution flow: 1. Admin configures an action in glances.conf (documented feature): 2. When the threshold is exceeded, the plugin model renders the template with runtime stats…
Recommended action: Upgrade to 4.5.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Glances web server runs without authentication by default when started with glances -w, exposing REST API with sensitive system information including process command-lines containing credentials (passwords, API keys, tokens) to any network client. Details Root Cause: Authentication is optional and disabled by default. When no password is provided, the API router initializes without authentication dependency, and the server binds to 0.0.0.0 exposing all endpoints. Affected Code: - File: glances/outputs/glancesrestfulapi.py, lines 259-272 - File: glances/outputs/glancesrestfulapi.py, lines 477-480 - File: glances/outputs/glancesrestfulapi.py, lines 98-99 - File: glances/plugins/processlist/init.py, lines 127-140 PoC 1. Start Glances in default web server mode: 2. Access API without authentication from any network client: <img width="593" height="265" alt="image" src="https://github.com/user-attachments/assets/4ec461be-b480-46d5-88e2-f4004f4dae54" / 3. Extract system…
Recommended action: Upgrade to 4.5.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The TimescaleDB export module constructs SQL queries using string concatenation with unsanitized system monitoring data. The normalize() method wraps string values in single quotes but does not escape embedded single quotes, making SQL injection trivial via attacker-controlled data such as process names, filesystem mount points, network interface names, or container names. Root Cause: The normalize() function uses f"'{value}'" for string values without escaping single quotes within the value. The resulting strings are concatenated into INSERT queries via string formatting and executed directly with cur.execute() — no parameterized queries are used. Affected Code - File: glances/exports/glancestimescaledb/init.py, lines 79-93 (normalize function) - File: glances/exports/glancestimescaledb/init.py, lines 201-205 (query construction) PoC - As a normal user, create a process with the name containing the SQL Injection payload: - Start Glances with TimescaleDB export as root user:…
Recommended action: Upgrade to 4.5.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The /api/4/config REST API endpoint returns the entire parsed Glances configuration file (glances.conf) via self.config.asdict() with no filtering of sensitive values. The configuration file contains credentials for all configured backend services including database passwords, API tokens, JWT signing keys, and SSL key passwords. Details Root Cause: The asdict() method in config.py iterates over every section and every key in the ConfigParser and returns them all as a flat dictionary. No sensitive key filtering or redaction is applied. Affected Code: - File: glances/outputs/glancesrestfulapi.py, lines 1154-1167 - File: glances/config.py, lines 280-287 - File: glances/outputs/glancesrestfulapi.py, lines 472-475 (authentication bypass) PoC - Start Glances in default webserver mode: - From any network-reachable host, retrieve all configuration secrets: Step 3: Extract specific secrets: Impact Full Infrastructure Compromise: Database credentials (InfluxDB, MongoDB,…
Recommended action: Upgrade to 4.5.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.