CVE-2026-32611

Description

## 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`): ```python 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`): ```python 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`): ```python 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: 1. Using `psycopg.sql.Identifier()` for table and column names 2. Using `psycopg.sql.SQL()` for composing queries 3. 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: ```python # 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 # ); ``` ```bash # 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: ```python # 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() ```

Priority Score