Collaboration makes us all stronger

Collaboration makes us all stronger | Databricks Blog Skip to main content

Summary

Databricks and an external security researcher successfully collaborated to identify and mitigate a memory-safety vulnerability within the open-source PostGIS address_standardizer extension, reachable by any tenant on managed Postgres platforms, including Lakebase Postgres and Neon. Databricks’ architecture prevented cross-customer exposure.

By treating the third-party vulnerability as their own responsibility, Databricks rapidly deployed a downstream patch to protect customers immediately instead of waiting for an upstream open-source release.

The researcher generously donated his bug bounty back to the volunteer PostGIS maintainers, and a comprehensive fix was ultimately contributed upstream to secure the broader Postgres ecosystem.

The best security bugs come with a good story 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.

What Mehmet found 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. The researcher's perspective 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. How Databricks and Neon responded 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...