CVE-2026-32611: Nicolargo Glances SQLI Vulnerability

CVE-2026-32611 Overview

CVE-2026-32611 is a critical SQL Injection vulnerability affecting Glances, an open-source cross-platform system monitoring tool. The vulnerability exists in the DuckDB export module (glances/exports/glances_duckdb/__init__.py) where table names and column names derived from monitoring statistics are directly interpolated into SQL statements via f-strings. While a previous fix (commit 39161f0) addressed SQL injection in the TimescaleDB export module using parameterized queries, the DuckDB export module was not included in that remediation and contains the same class of vulnerability.

Critical Impact

Attackers with network access can exploit unsanitized SQL identifier interpolation in the DuckDB export module to execute arbitrary SQL commands, potentially leading to unauthorized data access and data manipulation.

Affected Products

• Nicolargo Glances (versions prior to 4.5.3)

Discovery Timeline

• 2026-03-18 - CVE CVE-2026-32611 published to NVD
• 2026-03-19 - Last updated in NVD database

Technical Details for CVE-2026-32611

Vulnerability Analysis

This vulnerability stems from an incomplete security fix. When the Glances development team addressed SQL injection in the TimescaleDB export module (GHSA-x46r), they converted SQL operations to use parameterized queries and psycopg.sql composable objects. However, the DuckDB export module was overlooked during this remediation effort and retained the vulnerable code pattern.

The core issue lies in how the DuckDB module constructs DDL (Data Definition Language) statements and table name references. While the INSERT statement values already use parameterized queries with ? placeholders, the identifier names (table names and column names) are not escaped or parameterized. This allows an attacker who can influence the monitoring statistics data to inject malicious SQL through crafted identifier names.

Root Cause

The root cause is improper input validation and lack of identifier sanitization in the DuckDB export module. When constructing SQL statements, the module uses Python f-strings to directly interpolate table and column names derived from monitoring statistics into SQL queries. DuckDB, like most SQL databases, requires proper escaping of identifiers using double-quote escaping conventions, which was not implemented in the vulnerable code.

Attack Vector

An attacker with network access to the Glances monitoring tool can exploit this vulnerability by injecting malicious SQL through crafted monitoring statistic names. Since the vulnerability exists in the export functionality, any data being exported to DuckDB that contains specially crafted identifiers could trigger SQL injection. The attack does not require authentication and can be executed remotely, potentially allowing attackers to read sensitive data, modify database contents, or manipulate the underlying DuckDB database.

# Security patch implementing proper identifier quoting
# Source: https://github.com/nicolargo/glances/commit/63b7da28895249d775202d639e5531ba63491a5c

from glances.exports.export import GlancesExport
from glances.logger import logger


def _quote_identifier(name):
    """Quote a SQL identifier to prevent injection.

    DuckDB uses standard double-quote escaping for identifiers.
    Any embedded double-quote is doubled to escape it.
    """
    return '"' + str(name).replace('"', '""') + '"'


# Define the type conversions for DuckDB
# https://duckdb.org/docs/stable/clients/python/conversion
convert_types = {

The security patch introduces a _quote_identifier() function that properly escapes SQL identifiers by wrapping them in double quotes and doubling any embedded double-quote characters, following DuckDB's standard escaping convention.

Detection Methods for CVE-2026-32611

Indicators of Compromise

• Unusual or malformed table names in DuckDB database exports containing SQL metacharacters such as double quotes, semicolons, or SQL keywords
• Error logs indicating SQL parsing failures or unexpected query structures in the Glances DuckDB export module
• Unexpected database schema changes or tables created with suspicious names

Detection Strategies

• Monitor Glances application logs for SQL syntax errors or unusual database operations
• Implement database activity monitoring on DuckDB instances receiving Glances exports
• Review network traffic for anomalous monitoring data payloads containing SQL injection patterns

Monitoring Recommendations

• Enable verbose logging for the Glances DuckDB export module to capture all SQL operations
• Implement alerting on database query failures that may indicate injection attempts
• Audit DuckDB database schemas periodically for unauthorized or suspicious table and column names

How to Mitigate CVE-2026-32611

Immediate Actions Required

• Upgrade Glances to version 4.5.3 or later which contains the complete fix for this vulnerability
• If immediate upgrade is not possible, disable the DuckDB export module until patching is complete
• Review DuckDB databases that received exports from vulnerable Glances instances for signs of exploitation

Patch Information

The vulnerability is fixed in Glances version 4.5.3. The security patch introduces proper identifier quoting using the _quote_identifier() function that escapes SQL identifiers according to DuckDB's double-quote escaping convention. The fix is available in commit 63b7da28895249d775202d639e5531ba63491a5c. For additional technical details, refer to the GitHub Security Advisory GHSA-49g7-2ww7-3vf5.

Workarounds

• Disable the DuckDB export functionality by removing or commenting out the [duckdb] configuration section in glances.conf
• Use alternative export modules (such as CSV or JSON) that do not involve SQL operations until the patch is applied
• Implement network segmentation to restrict access to Glances monitoring endpoints

# Configuration example - Disable DuckDB export by commenting out or removing this section
# In glances.conf:
# [duckdb]
# database=:memory:

# Alternative: Use in-memory database to limit exposure (still vulnerable but reduces persistence)
[duckdb]
database=:memory: