CVE-2026-29089: 
NixOS vulnerability analysis and mitigation

CVE-2026-29089 is an untrusted search path vulnerability in TimescaleDB, a time-series database packaged as a PostgreSQL extension, that allows a low-privileged local user to execute arbitrary code with superuser privileges during extension upgrades. It affects TimescaleDB versions 2.23.0 through 2.25.1 and was disclosed on March 6, 2026, with a patch released in version 2.25.2 on March 3, 2026. The vulnerability carries a CVSS v3.1 base score of 8.8 (High) (GitHub Advisory, Red Hat Bugzilla).

The root cause is CWE-426 (Untrusted Search Path): TimescaleDB's SQL install, upgrade, and downgrade scripts did not explicitly set the search_path at the start of execution, relying instead on the session-level search_path setting (GitHub Advisory). PostgreSQL resolves unqualified database object names (tables, functions, operators) by searching schemas in the order defined by search_path; if a user-writable schema appears before pg_catalog, a malicious user can create shadow functions in that schema that override built-in PostgreSQL functions (GitHub PR #9331). When a database administrator subsequently runs ALTER EXTENSION timescaledb UPDATE, the upgrade script invokes these shadowed functions instead of the legitimate built-ins, resulting in arbitrary code execution. The fix introduced a header.sql file prepended to all SQL scripts that explicitly executes SET LOCAL search_path TO pg_catalog, pg_temp;, neutralizing the attack vector (GitHub Commit).

Successful exploitation allows a low-privileged database user to escalate privileges to PostgreSQL superuser level, resulting in full compromise of the database system — including unauthorized access to all data (confidentiality), modification or deletion of any database content (integrity), and potential disruption of database services (availability) (GitHub Advisory). The CVSS scope is marked "Changed," reflecting that the impact extends beyond the attacker's own database session to the broader PostgreSQL instance and potentially the underlying host OS if the superuser account has OS-level privileges (Feedly). Notably, instances hosted on Timescale's Tiger Cloud and Managed Service for TimescaleDB are not affected due to additional platform-level security controls (GitHub Advisory).

No public proof-of-concept exploit code or evidence of in-the-wild exploitation has been reported as of the time of disclosure (Feedly). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.012% (0.000120), indicating a very low probability of exploitation in the near term. Exploitation requires local database access with at least low privileges and the ability to create objects in a user-writable schema that appears in the search_path, and is only triggered when a privileged user performs an extension upgrade.

1. Gain database access: Obtain a low-privileged PostgreSQL user account on a TimescaleDB instance running versions 2.23.0–2.25.1, with CREATE privileges on at least one schema that appears in the session search_path before pg_catalog.
2. Identify the search_path: Query the current search_path setting with SHOW search_path; to identify user-writable schemas that are resolved before system schemas.
3. Create a malicious shadow function: In the user-writable schema, create a function with the same name and signature as a PostgreSQL built-in function called during TimescaleDB's upgrade script (e.g., a function invoked without schema qualification). For example:

   CREATE OR REPLACE FUNCTION public.some_builtin_function(...) RETURNS ... AS $$ BEGIN -- malicious payload, e.g., GRANT superuser TO attacker_role; END; $$ LANGUAGE plpgsql;

4. Wait for or trigger an extension upgrade: The attack is activated when a superuser runs ALTER EXTENSION timescaledb UPDATE;. This can be triggered by a database administrator performing routine maintenance or an automated upgrade process.
5. Achieve privilege escalation: During the upgrade, the TimescaleDB SQL script calls the unqualified function name, which resolves to the attacker's shadow function instead of the legitimate built-in, executing the malicious payload with superuser context (GitHub Advisory, GitHub PR #9331).

• Database Logs: PostgreSQL logs (postgresql.log) showing ALTER EXTENSION timescaledb UPDATE executed around the time of suspicious privilege changes or unexpected function calls from non-system schemas.
• Database Objects: Presence of functions in user-writable schemas (e.g., public) that share names with PostgreSQL built-in functions — query with SELECT n.nspname, p.proname FROM pg_proc p JOIN pg_namespace n ON p.pronamespace = n.oid WHERE n.nspname NOT IN ('pg_catalog','information_schema','timescaledb_internal') AND p.proname IN (SELECT proname FROM pg_proc WHERE pronamespace = 'pg_catalog'::regnamespace);
• Privilege Changes: Unexpected superuser grants or role membership changes in pg_authid or audit logs following an extension upgrade event.
• search_path Configuration: Non-default search_path settings that place user-writable schemas (e.g., public) before pg_catalog, detectable via SELECT usename, useconfig FROM pg_user; or pg_database.datconfig.

The primary remediation is to upgrade TimescaleDB to version 2.25.2 or later, which prepends SET LOCAL search_path TO pg_catalog, pg_temp; to all SQL installation and upgrade scripts (GitHub Release 2.25.2). As a workaround for environments that cannot immediately upgrade, blocking extension upgrades (i.e., preventing execution of ALTER EXTENSION timescaledb UPDATE) will prevent exploitation (GitHub Advisory). Additionally, administrators should restrict the search_path to exclude user-writable schemas and limit database CREATE privileges to trusted users only.

The vulnerability was published by Timescale maintainer svenklemm via GitHub Security Advisories on March 3, 2026, with an urgent recommendation to upgrade (GitHub Advisory). Red Hat tracked the issue via Bugzilla (Bug 2445265) and the Red Hat CVE advisory page, classifying it as high severity (Red Hat Bugzilla). Coverage appeared on The Hacker Wire and several vulnerability aggregation platforms shortly after disclosure, though no significant community controversy or notable researcher commentary beyond standard reporting has been observed.