CVE-2026-1117 and why function-name collisions are back

CVE-2026-1117 disclosed last week. PostgreSQL function-name resolution can, under a specific search_path configuration, prefer a same-named function in an attacker-controlled schema over the intended one. It is dressed-up as a Postgres bug, but the real story is what we have been doing in modern ORMs.

the historical version

Function-name collisions are not new. The 2007 advisory described the same primitive: if a user has CREATE permission on any schema in search_path, they can shadow built-in functions. The classic guidance is "do not put untrusted schemas in search_path." The vast majority of databases follow it.

why it is relevant again

Drizzle, Prisma, and a handful of newer ORMs ship extensions that auto-register helper schemas to support row-level security and tenant-aware joins. The extension adds app_helpers to search_path at session start. If a tenant has CREATE permission inside their own schema — and many multi-tenant designs grant exactly this — and the ORM's session pool reuses the same physical connection across tenants, you get a window where one tenant can shadow a helper function the next tenant calls.

We do not have data on how many production databases are affected because most teams do not log search_path changes. We did find this exact primitive in a customer staging tenant in March, and we have shipped a check for it as part of our authz-01 agent.

the fix

drizzle.config.ts// pin search_path per session, never trust the pool default
const db = drizzle({
  client: pool,
  onConnect: async (client) => {
    await client.query("SET search_path = 'public', 'pg_catalog'");
  },
});

If you cannot pin search_path because your extension genuinely needs the helper schema, you should at minimum revoke CREATE on the tenant schemas from the tenant-level role. The principle is the same one the 2007 advisory laid down: if any schema in search_path is writable by a hostile party, you have lost.