Vulnerability researcher Mehmet Ince published Part 2 of a six-part series documenting 76 flaws across the security-hardening extensions that Azure, AWS Aurora, Aiven, Supabase, PlanetScale, Xata, Google AlloyDB and NeonDB use to fence in the superuser-like role they hand customers on managed PostgreSQL. The bugs share a small set of root causes, and most vendors have not fixed them yet.
What changed
Ince's report groups the 76 findings into four recurring bug classes. The first is foreign data wrapper (FDW) validator abuse: vendor code typically switches current_user to superuser, delegates to PostgreSQL core, then restores the original role, but never checks that the validator function's OID is actually safe — a malicious validator function can call CREATE ROLE ... SUPERUSER while running in that elevated window. The second is a search_path OID-switching attack, where an attacker plants a same-named function (for example postgres_fdw_validator) earlier in the search path, so the elevated context resolves a different OID than the one that was checked. The third is an lo_export() bypass: instead of the blocked function itself, the attacker updates pg_catalog.pg_proc.prosrc and creates a new LANGUAGE internal function that redirects to the real lo_export implementation, writes an arbitrary file to disk, loads it as a PostgreSQL extension .so, and reaches LANGUAGE C code execution. The fourth class is broader: LANGUAGE internal type-confusion bugs that give raw read/write access to PostgreSQL's process memory, which Ince argues makes the hardening extensions "effectively useless" as a security boundary. Patch status is uneven — Supabase fixed four of the FDW-related bugs, only two vendors properly protect pg_proc against the lo_export bypass, and the LANGUAGE internal memory bugs remain open almost everywhere. The PostgreSQL core team's position, per the report, is that when a provider does not intend to grant full superuser access, the resulting security gap belongs to the provider's service, not to PostgreSQL itself. Part 1 of the series covered a PostGIS memory-corruption bug; Part 3 onward is reported to cover more than 16 PostgreSQL core vulnerabilities that remain under embargo.
Who this affects
Anyone running production workloads on a managed PostgreSQL service that grants a restricted "superuser-like" role instead of true superuser — Azure Database for PostgreSQL, AWS Aurora PostgreSQL, Aiven, Supabase, PlanetScale, Xata, Google AlloyDB or NeonDB — should read this. That role's isolation guarantees rest entirely on the vendor's hardening extension, and this research shows those guarantees have concrete holes today, not hypothetical ones.
Teams that manage their own PostgreSQL instances with real superuser access are not affected by these specific bugs, since there is no restricted-role boundary to break. Extension authors building similar "safe superuser" abstractions on LANGUAGE internal or FDW validators should treat this as a design-pattern warning, independent of any single vendor's patch status.
Verdict
This is not an upgrade-or-wait decision about a piece of software — it is a trust decision about a security boundary. Given that only a fraction of the 76 findings have confirmed fixes (four FDW bugs at Supabase, pg_proc protection at two vendors) and the LANGUAGE internal memory-corruption class remains open almost everywhere, the restricted "superuser" role on most affected platforms should not currently be treated as an isolation guarantee against a determined attacker with access to that role.
Teams on the named platforms should check with their vendor for a patch timeline before assuming the hardening extension protects them, and should avoid granting the restricted role to less-trusted users or automated agents in the meantime. Because Part 3 of the series is reported to disclose more than 16 additional PostgreSQL core vulnerabilities still under embargo, this is better read as the second chapter of an ongoing disclosure than a closed incident.
Tracked daily from official release feeds and vendor changelogs. Full archive: https://media.patentllm.org
Top comments (0)