The Postgres Extension That Quietly Held the Database Hostage

Postgres extensions are not sandboxed. When you run CREATE EXTENSION, its install script executes with the privileges of whoever ran the command, which in practice is almost always a superuser, and every function and object it creates then joins the trusted core of the database. There is no smaller box the code runs inside.

"Held hostage" here is a metaphor for covert seizure of superuser control, not ransomware or encrypted data. Several unrelated extensions, from pg_cron to logical replication, have hit the same failure class: code meant to run with reduced privilege ends up running as whoever triggers it later. Once that happens, the extension owns the database.

pg_cron stores scheduled jobs in a table cron.job, keyed by a jobid primary key, and loads them into an in-memory hash table before it checks who is allowed to run them as superuser. A low-privileged user who owns cron.job can exploit that ordering.

Because the in-memory job struct is built and hashed by jobid before the superuser check rejects the planted row, the legitimate task ends up pointing at the overwritten postgres entry in the hash table. The background worker then connects as postgres and runs the attacker's SQL, even with cron.enable_superuser_jobs explicitly turned off. The fix landed in pg_cron 1.6.5.

Extension install scripts often use CREATE OR REPLACE on their functions and views. If an object with that exact name and signature already exists, planted in advance by a low-privileged user with CREATE rights in the public schema, the install blindly adopts it and grants it the extension's elevated privileges. This is CVE-2022-2625, affecting PostgreSQL 10 through 14 at a CVSS of 7.1.

This is the closest thing to a literal hostage: the trap sits dormant with no immediate effect until an admin installs a specific extension, possibly weeks later. PostgreSQL 15 shrank the attack surface by revoking CREATE on the public schema from PUBLIC by default, which stops most planting, though re-granting CREATE to untrusted roles reopens it.

Postgres separates session_user, your real login, from current_user, the effective user that a SECURITY DEFINER function or SET ROLE can switch. That mechanism was originally built in 2008 to raise privilege, then adapted to safely drop it for maintenance work like VACUUM FULL and ANALYZE, which is where the sharp edges live.

The security-restricted operation sandbox blocks anything that could persist past the privileged step, like temp tables or deferred triggers, so no "time bomb" fires after privileges revert. But five classic vectors keep letting one user's object run inside another's context: triggers, index functions, CHECK constraints, DEFAULT expressions, and rules or views.

CVE-2024-0985 shows the pattern: a late privilege drop in REFRESH MATERIALIZED VIEW CONCURRENTLY let a view's creator run arbitrary functions as whoever issued the refresh, often a superuser lured into it. The trick used CREATE RULE to turn the internal temp table into a view, escaping the sandbox at the moment privileges dropped too late; the fix shipped in Postgres 16.2.

IBM Cloud exposed logical replication to customers through a custom create_subscription function, owned by the ibm superuser role and marked SECURITY DEFINER. It built a dblink_exec call by string-formatting user-supplied parameters without sanitizing them, so a crafted db_name or host_ip broke out of the intended statement and ran attacker SQL as superuser.

The reason this hit a managed service and not a laptop is delegation. Default Postgres only lets superusers create subscriptions, but cloud providers hand that power to customer roles, which widens the blast radius exactly where the trust model is weakest. From one injected string the researchers reached command execution, a Kubernetes service-account token, and finally the internal build pipeline.