CVE-2026-32611 in glances
Summary
by MITRE • 03/18/2026
Glances is an open-source system cross-platform monitoring tool. 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. Version 4.5.3 provides a more complete fix.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 03/24/2026
CVE-2026-32611 represents a critical SQL injection vulnerability affecting the Glances monitoring tool's DuckDB export module, demonstrating a persistent pattern of insecure database query construction that violates fundamental security principles. This vulnerability stems from the improper handling of database identifiers within the export functionality, specifically in how table and column names are constructed for DuckDB operations. The issue manifests when monitoring statistics data is processed and directly interpolated into SQL statements using f-strings, creating an attack surface where malicious input could manipulate the database schema construction process. The vulnerability is categorized under CWE-89 SQL Injection, which occurs when untrusted data is incorporated into SQL queries without proper sanitization or parameterization, and aligns with ATT&CK technique T1070.004 Indicator Removal on Host to potentially conceal malicious activities. The flaw exists because while the values being inserted into DuckDB tables properly utilize parameterized queries with ? placeholders, the Data Definition Language (DDL) operations that create or reference database objects do not employ similar protective measures. This differential security treatment creates a dangerous inconsistency where the insertion layer is hardened but the schema construction layer remains vulnerable, allowing attackers to inject malicious identifiers that could alter the intended database structure or execute unauthorized operations.
The operational impact of this vulnerability extends beyond simple data corruption, as it could enable attackers to manipulate the monitoring tool's data export capabilities to gain unauthorized access to the underlying database system. When the DuckDB export module processes monitoring statistics, it constructs SQL statements that reference dynamically generated table names and column names, which are then directly embedded into the SQL commands without proper escaping or validation. This creates a scenario where an attacker could potentially inject malicious table or column names that could redirect the export process to unintended database operations, potentially leading to data exfiltration, schema modification, or even database privilege escalation. The vulnerability is particularly concerning in environments where Glances is used for security monitoring, as it could be exploited to manipulate the very data that security teams rely upon for detecting threats. The fix implemented in version 4.5.3 addresses this by ensuring that all SQL operations in the DuckDB module follow the same security patterns established in the TimescaleDB fix, converting identifier interpolation to use proper parameterized queries and composable objects that prevent malicious injection attempts. This remediation aligns with industry best practices for database security and follows the principle of least privilege by ensuring that database identifiers are properly sanitized regardless of their source.
The vulnerability demonstrates a common oversight in security implementations where fixes are applied selectively to known vulnerable components while similar issues in other modules are overlooked, creating a false sense of security. This pattern of incomplete remediation highlights the importance of comprehensive security reviews and the need for consistent security practices across all code modules. The issue is particularly relevant in the context of continuous monitoring systems where data integrity is paramount, as any compromise of the export functionality could undermine the entire security monitoring infrastructure. Organizations using Glances for system monitoring should prioritize updating to version 4.5.3 or later to ensure that all export modules are properly secured against SQL injection attacks. The fix implemented addresses both the immediate vulnerability and establishes a more robust framework for future development by ensuring that all database identifier handling follows consistent security patterns. This vulnerability also serves as a reminder of the importance of security testing across all components of monitoring tools, particularly those that interact with database systems, as the export functionality often represents a critical attack vector for compromising system integrity and confidentiality.