Skip to content

DATABRICKS 2026-09-01

Read original ↗

Collaboration makes us all stronger

Summary

Databricks tells the story of a coordinated-disclosure interaction with external researcher Mehmet Ince (CTO of threat-intel firm PRODAFT) around a memory-safety bug in the address_standardizer extension that ships inside PostGIS — an extension available to ordinary tenants on managed Postgres platforms including Databricks' Lakebase Postgres and Neon. The bug is a classic out-of-bounds memory access: a caller-controlled value (part of a grammar "rule" the caller supplies) is used to index a fixed-size internal array without a bounds check. Because address_standardizer is installable/callable by a normal tenant role, the vulnerable code path is reachable without special privileges — the property that turns a sleepy extension bug into a platform-team problem. The post's real subject is the response: Neon's production alarms detected the researcher's exploit testing, a Databricks security engineer (Aaron) proactively reached out, and the team drove the fix rather than deflecting it as "third-party." Two architectural points make the story: (1) Databricks runs Lakebase/Neon on a microVM architecture whose strong compute-instance boundary meant the exploit produced no cross-customer impact on Databricks (in contrast to cross-customer data exposure the researcher observed on another platform); and (2) their extension build system can apply an arbitrary patch set on top of any upstream Postgres extension before compile — backport a fix or disable a risky code path — so they could protect customers without waiting on an upstream PostGIS release. The canonical fix was then driven back upstream into PostGIS for the whole managed-Postgres ecosystem.

Key takeaways

  1. A bug in an OSS component you ship is your bug. The root cause lived upstream in PostGIS, but the exposure was Databricks': "We put that extension in front of tenants by default, so the impact was ours to own." They accepted the report, drove the response, and rewarded the researcher rather than waving it off as third-party. This is the own-your-exposure principle.

  2. Reachability, not just the bug, is what matters for a managed service. address_standardizer is on the set of extensions a normal tenant can install and call, 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." Privilege-to-reach is the property that reclassifies a quiet memory bug as a platform risk. (Source: this article.)

  3. The vulnerability is a textbook memory-safety flaw. A value the caller fully controls (part of a grammar rule) indexes a fixed-size internal array with no bounds check → out-of-bounds memory access. Same bug class the wiki tracks from Aurora DSQL / WhatsApp wamedia: new/edge code in a C/C++ codebase, not the battle-tested core.

  4. microVM isolation contained the blast radius. "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 researcher's own write-up references cross-customer data exposure on a different platform — so the isolation architecture is the difference between "memory corruption in a shared extension" and "cross-tenant breach." See concepts/micro-vm-isolation and concepts/blast-radius.

  5. A downstream patch lever decouples customer protection from the upstream release timeline. "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 the patch set lives downstream, they can act independently of when upstream cuts a release — "what turns 'we know about it' into 'customers are protected.'" See downstream-patch-lever-for-shipped-oss.

  6. The durable fix took iterations, and the real fix went upstream. The first hardening pass "didn't cover every case"; they took an extra week rather than ship something narrow, deployed the hardened fix to Neon and Lakebase tenants (no customer action required), then worked with the researcher to fix the root cause in PostGIS so everyone running address_standardizer benefits — the upstream the fix pattern.

  7. The upstream fix was incomplete, and no CVE was assigned. Around the same time the underlying bug was patched upstream as a small memory-leak fix "without a CVE and without fanfare." That fix didn't cover every case; Mehmet validated where it fell short and submitted the remaining pieces upstream. Lesson: "how easy it is for a meaningful memory-safety fix to slip into a release note as a 'minor' cleanup."

  8. Coordinated disclosure is a relationship, and detection makes it work. Neon's production alarms caught the exploit testing; a single screenshot of a working PoC was enough for the security team to start acting. The researcher donated (and personally matched) his bounty to the volunteer PostGIS project. Report channel: hackerone.com/databricks.

Systems / concepts / patterns extracted

  • Systems: PostGIS (the shipping OSS component; hosts the address_standardizer extension), Lakebase Postgres and Neon (the two affected managed-Postgres surfaces, both on the microVM architecture), PostgreSQL (the extension host).
  • Concepts: concepts/memory-safety (out-of-bounds indexing via caller-controlled value), concepts/micro-vm-isolation (the boundary that contained the exploit), concepts/tenant-isolation, concepts/blast-radius, own-your-exposure-not-just-your-code (new).
  • Patterns: downstream-patch-lever-for-shipped-oss (new — patch/disable an OSS extension in your own build ahead of upstream), patterns/upstream-the-fix (drive the root-cause fix back to PostGIS), postgres-extension-over-fork (PostGIS as the canonical extension-not-fork instance and the reason the whole industry shares this attack surface).

Operational details / numbers

  • Affected extension: address_standardizer, a small sub-extension inside PostGIS that normalizes unstructured addresses (e.g. 123 Main St).
  • Bug: caller-controlled grammar-rule value indexes a fixed-size internal array without a bounds check → out-of-bounds memory access.
  • Reachability: installable and callable by a normal (non-privileged) tenant role.
  • Affected managed surfaces: Lakebase Postgres and Neon (both Databricks, both microVM-isolated); researcher also targeted Neon Postgres instances directly during PoC.
  • Cross-customer impact on Databricks: none (attributed to the microVM compute-instance boundary).
  • Fix cadence: first hardening pass incomplete → ~1 extra week for a complete hardened fix; deployed to Neon + Lakebase tenants with no customer action required.
  • Upstream: underlying bug patched upstream as a memory-leak fix, no CVE; incomplete; researcher submitted the remaining pieces upstream. No CVE assigned for the chain.
  • Researcher: Mehmet D. Ince, CTO of PRODAFT (European threat-intel firm, ~50 engineers), 20+ years of responsible disclosure. Donated + personally matched his bounty to the PostGIS project.

Caveats

  • First-party engineering/security blog; deliberately light on exploitation detail (deferred to the researcher's own deep-dive). The primitive itself is not fully described here.
  • "No cross-customer impact on Databricks" is a first-party claim; the microVM boundary is asserted as the reason but its internals are not detailed in this post (see the companion Lakebase reliability/architecture posts for the storage/compute + isolation model).
  • The competing-platform cross-customer exposure is referenced via the researcher's blog, not independently characterized here.

Source

Last updated · 766 distilled / 2,225 read