Part 1/6 | Systemic Risks in the Managed PostgreSQL Industry: Extension Risks Are Real! Exploiting PostGis Memory Corruption Bug at NeonDB, SupaBase and Many More - Mehmet Ince @mdisec - Vulnerability Researcher | Building security products | Security Advisor | Amateur Muay Thai fighter
Skip to content
YouTube
GitHub
Part 1/6 | Systemic Risks in the Managed PostgreSQL Industry: Extension Risks Are Real! Exploiting PostGis Memory Corruption Bug at NeonDB, SupaBase and Many More
Jul 28, 2026
Back in April, I was talking with our system and software engineering teams at PRODAFT about the possibilities of using a managed database service. Due to the nature of our business, we simply cannot start using managed services right away. I told my team, “Alright, I will have a look at a few companies and let’s see how we can start using—more like trusting—these services,” and left the meeting.
I have a somewhat unconventional approach to vendor selection. Before we seriously consider adopting new open-source projects, I give myself a research window and read the source, which unsurprisingly almost always ends up with me reporting a critical vulnerability to the vendors[1][2]. Old habits die hard.
A few weeks later, I finally had time to try out different vendors to understand this industry better. Yes, we have been using PostgreSQL ever since I founded Prodaft with my partners more than a decade ago, but I have not reviewed the industry or how they provide those services, especially from a cybersecurity perspective.
On a lovely Monday morning, a few hours into reading source code and trying things out, I had to tweet the following post because I found a chain of issues that let me reach different customers’ production databases.
The same mistake was affecting Supabase as well as a few other vendors. Both of those vendors fixed that vulnerability within 30 minutes!
To be honest, I had no idea that over the following three months, I would spend all my free time outside my day job working on a research project I named “Systemic Risks in the Managed PostgreSQL Industry” finding vulnerabilities in number of different vendor that gave me cross-tenant access. I found critical issues in the underlying PostgreSQL infrastructure, such as CNPG, more than 40 vulnerabilities in the PostgreSQL extension ecosystem, as well as a logical vulnerability in the privilege-relaxation design, an inconsistency between PostgreSQL core features and managed-Postgres companies’ threat models, and many more.
I even ended up submitting a talk to PGConf EU 2026 in Valencia this October titled Nobody Gets to Be Superuser (Until I Broke In) to talk about all of these issues together. So if you are going to be around there, drop me a DM!
Ever since I submit that talk to pgconfeu, my findings has gotten way deeper and interesting so I wont be able to cover everything in a single session. Therefore I am planning to release 5 more articles that each of them will be dedicated to a different aspect of my research, but obviously I wanted to start with the most popular topic because it was my starting point to this journey too.
This article focuses on the well-known popular risks: extensions! It presents a detailed case study of how a single vulnerability in a PostgreSQL extension with a four-star rating on the GitHub repo enabled me to achieve privilege escalation on NeonDB, Supabase, Xata, and several other providers whose names I cannot disclose yet.
2nd article is going to be about my 5 different PostgreSQL core remote code execution 0-days that I have exploited, literally everywhere! It works on 18.6 published at 13 Aug 2026, and all the version 14 through 19, plus current master. (If you’re working for a managed-Postgres provider, get in touch with me to be read in!)
3rd one is going to be more about underlying systems that runs postgres at scales and its burdens to whole threat model.
4rd one will be all about security hardening extensions that every vendors fails more or less the same way.
So as I gather my research notes, I will publish things I learn. So feel free to follow me on @X.
TLDR:
A missing bounds check in PostGIS’s address_standardizer extension turned a user-controlled rule value into an out-of-bounds write primitive. By chaining it with a separate memory-disclosure bug, I was able to escalate my privileges to superuser by using my own technique to flipping the rolsuper flag on local backend caches to stay under the radar, and reach RCE in production on NeonDB, Supabase, Xata, and several other managed PostgreSQL providers.
If you are not interested in the deep-dive exploitation details, feel free to jump straight to sections 12 and 13, or to My Thoughts and Closing Notes at the end.
1 – Choosing a Target: address_standardizer Postgres Extension
I realised something in the early stages of my research months ago. There are quite a large number of layers in those tech stacks where I can actually start...