A Lakebase Postgres disclosure case study
by Aaron Kobayashi, Mehmet D. Ince, Anurag Srivastava and Alexey Kondratov
Some of our best security investments haven't been tools or scanners. They've been in relationships. Databricks runs a bug bounty program because the fastest way to find the sharp edges in a platform is to let talented, curious people go looking for them, and to make sure that when they find something, a good-faith report is met with a good-faith response. Most reports are a quiet transaction: someone finds a bug, we fix it, and everyone moves on.
Every so often, one of them turns into a genuinely good story. This is one of those.
A few weeks ago, an external researcher, Mehmet Ince, showed us a memory-safety bug in a Postgres extension that ships on managed Postgres platforms, including Lakebase Postgres and Neon. What made it worth writing about isn't just the bug. It's what happened around it: how our detection caught his testing, how quickly we could protect customers, and how the real fix ended up back where it belonged. In open source, for everyone who runs the same extension, not just us.
If you run a security team, operate managed open-source infrastructure, or you're just curious what a healthy researcher-vendor interaction actually looks like from both sides, this one's for you. Mehmet has written up the deep technical exploitation story on his own blog. Here, we want to talk about the collaboration.
| Mehmet’s blog references cross-customer data exposure on a different platform. Databricks runs Lakebase Postgres and Neon on a microVM architecture that provides a strong security boundary between compute instances. Mehmet’s exploit did not result in any cross-customer impact on Databricks. |
|---|
The Postgres extension ecosystem is a major driver of its popularity, and though support varies by vendor, customers expect managed providers to support the most widely used core and third-party options. One of those is PostGIS, the geospatial toolkit. Inside PostGIS is a smaller, unassuming extension called address_standardizer that turns an unstructured address like 123 Main St into a normalized form.
Mehmet found that address_standardizer had a classic memory-safety flaw: a value a caller fully controls (part of a grammar "rule" the caller can supply) was used to index into a fixed-size internal array without a bounds check. Feed it a value that's out of range, and you get an out-of-bounds memory access.
The important part for a managed Postgres service is who can reach it. address_standardizer is on the set of extensions that a normal tenant can install and use. So this wasn't a bug that needed special privileges to touch. An ordinary customer role could call the function and reach the vulnerable code path. That's exactly the property that turns a quiet, easy-to-overlook bug into something a platform team needs to take seriously.
We're deliberately keeping the exploitation details light here. Mehmet's deep-dive walks through the primitive properly, and he does it better than a summary would.
By Mehmet D. Ince
The story did not begin as vulnerability research. This spring, during an internal meeting, my team asked whether we could migrate a few of our PostgreSQL instances to a managed provider. As the CTO of PRODAFT, a European threat-intelligence company with around 50 engineers, one of my responsibilities is ensuring we provide the most secure services possible to our customers.
We had been running PostgreSQL ourselves for more than a decade, but I had never properly reviewed how managed-Postgres providers delivered these services from a security perspective. I've been doing vulnerability research since the early 2000s, so I always give myself a small window to do some security research and better understand the risk we are taking simply by adding another technology to our stack. Unsurprisingly, my "quick reviews" tend to end with a critical vulnerability report in someone's inbox. Some habits are difficult to leave behind.
A few days into my research, I realized that almost every provider ships roughly the same Postgres extensions. A memory-corruption vulnerability in a widely deployed extension is effectively a memory-corruption vulnerability in PostgreSQL itself. So I chose an extension named address_standardizer, a small PostGIS extension available literally everywhere, as my target.
One Monday evening at around 7 p.m. here in London, Aaron quite unexpectedly emailed me, asking whether the activity that triggered Neon's production alarms belonged to me. I was working on porting my working exploit to Neon PostgreSQL instances to see whether a single, simple bug in a small, innocent extension could really expose a privilege-escalation path there. I had a working PoC, but I sent him only a screenshot. That single screenshot was enough for him to start taking action!
I have been responsibly disclosing vulnerabilities to vendors for more than two decades, and even after all these years, it is still hard to explain the impact and risks of the findings without spending a lot of time finding the right contact to speak with. I must say, kudos to Aaron and the security team at Databricks for proactively reaching out to researchers like this and taking such rapid action!
See Mehmet’s post for more information.
From our side of the table, this is a case study in coordinated disclosure working the way it's supposed to.
Mehmet shared his proof, and by the end of the day, the report had circulated with the right people, with our security engineers validating it against the exact PostGIS version of Neon ships. We confirmed the vulnerable code path was reachable by a normal tenant role and treated it accordingly.
Early on, we made a deliberate call that we think is worth spelling out, because it's a question every platform team eventually faces: a bug in an open-source component you ship is still your problem. The root cause lay upstream in PostGIS, but the exposure was ours. We put that extension in front of tenants by default, so the impact was ours to own. We didn't wave it off as "third-party." Instead, we accepted the report, drove the response, and rewarded the researcher who raised it.
We also weren't willing to be gated on an upstream release timeline while customers were exposed. Our extension build system is intentionally designed so we can apply an arbitrary set of patches on top of any upstream Postgres extension before we compile and package it, whether that's backporting a fix or disabling a risky code path in our own build. Because that patch set lives downstream rather than in upstream's source, we can act independently of when upstream cuts a release. So we were able to act quickly to protect customers and work in parallel work to fix the ecosystem properly.
Building the durable fix took a couple of iterations. The first pass didn't cover every case, and we'd rather take an extra week and get it right than ship something narrow. The hardened fix was deployed to protect Neon and Lakebase tenants, who did not need to take any action themselves.
Here's where it gets interesting, and a little bit lucky.
The canonical fix belonged in PostGIS. It's their code, their release, their call. Databricks thanks the PostGIS maintainers, who keep a foundational piece of the geospatial world running largely as volunteers. Mehmet clearly felt the same way, and did something about it: he donated his bounty to the PostGIS project, and matched it out of his own pocket, putting the reward straight back into the volunteer effort whose code the entire managed-Postgres industry leans on. Our plan was straightforward: protect our customers first, then work with Mehmet to get the root cause fixed upstream so everyone running address_standardizer benefits, not just Neon.
Then a coincidence complicated things. Around the same time, the underlying bug got patched upstream, as a small memory-leak fix, without a CVE and without fanfare.
The upstream fix, it turned out, didn't cover every case. Mehmet validated exactly where it fell short and submitted the remaining pieces back upstream, closing the gap for the whole community. No CVE was assigned for the chain, which is its own small lesson about how easy it is for a meaningful memory-safety fix to slip into a release note as a "minor" cleanup.
The takeaway we care about: the researcher got to do the right thing with the root cause, upstream got a complete fix, and our customers were already protected while all of that played out.
If you operate a managed service built on open-source components (a managed database, a managed anything), the uncomfortable truth in this story is that your attack surface includes code you didn't write and a threat model its authors may never have signed up for. A small, popular, sleepy extension is exactly the kind of thing that's easy to ship and easy to forget.
A few things that worked for us, and might for you:
If you're a security researcher, we'd genuinely like to hear from you. Especially when you can show real, measurable impact on the platform, as Mehmet did. Report through hackerone.com/databricks.
Thank you to Mehmet Ince for a well-documented, good-faith report and for doing the right thing with the root cause upstream. Thank you to the PostGIS maintainers, whose open-source work is a huge part of the geospatial world that depends on it. And thank you to the Neon and Lakebase engineers who quickly and calmly turned a report into a deployed fix.
To every researcher working with us to make the platform safer: we see you, and we're grateful. See you on HackerOne.
Subscribe to our blog and get the latest posts delivered to your inbox.