PostGIS address_standardizer vulnerability fixed

A regular Postgres tenant could trigger memory corruption through the PostGIS address_standardizer vulnerability, a flaw Databricks disclosed on September 1 after a report from researcher Mehmet D. Ince.

Companies in this story

StartupHub profiles of the companies this article names, with funding and a one-liner from our database.

Databricks

$190.0B

A unified data analytics and AI platform built on the lakehouse architecture.

Neon

$1.0B

A serverless Postgres database with separation of storage and compute.

Bloomberg L.P.

$42.6B

Global financial, software, data, and media company providing real-time information and analytics.

HumanX

$23.0B

A company that organizes premier AI conferences and publishes data-driven reports on the AI economy.

It hit managed Postgres platforms that ship the extension by default, including Lakebase Postgres and Neon.

Databricks said its microVM architecture contained the exploit and stopped cross-customer exposure, even though the same bug could expose data on other providers.

How the bug actually works

The extension normalizes free form addresses using a grammar rule the caller supplies, and that rule contains a numeric value the caller fully controls. That value was used directly as an index into a fixed size internal array with no bounds check, so an out of range value reads or corrupts memory beyond the array, like handing a librarian a fake aisle number and watching them walk past the shelves without checking.

Because address_standardizer is installable by an ordinary tenant role, no privileged access is needed to reach the vulnerable code path.

Why this matters and what isn't fixed

Databricks treated the upstream PostGIS bug as its own exposure and shipped a downstream patch through its extension build system instead of waiting for upstream, protecting Neon and Lakebase tenants with no customer action required. Upstream later patched the same bug quietly as a minor memory leak fix without a CVE, and that fix missed cases until Ince validated the gap and contributed the rest, so anyone tracking only CVEs would have missed it.

Builders running managed open source should keep the lever to patch downstream, audit which extensions are enabled by default for untrusted roles, and don't assume an extension's threat model matches yours.

Neon, acquired by Databricks in May, brought the microVM isolation model that made the difference here. Not every managed Postgres isolates tenants that strongly, and Ince notes cross-customer exposure was possible elsewhere.

The bounty detail matters too. Ince donated his award to the volunteer PostGIS maintainers and matched it himself, a direct subsidy for code that a large share of managed databases depend on.

For platform teams the fix is shipped but the lesson isn't. Small extensions still set your security perimeter.